New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C# 7 Work List of Features #2136

Closed
MadsTorgersen opened this Issue Apr 21, 2015 · 463 comments

Comments

Projects
None yet
@MadsTorgersen
Contributor

MadsTorgersen commented Apr 21, 2015

(revision circa April 26 2016, clarifying edit June 14, 2016)

This is a list of features are looking at for C# 7, roughly categorized according to our current level of interest and estimated plausibility.

Please don't infer anything about the final shape of C# 7 (or future versions). The list is a tracking mechanism for work, not a description of the outcome. We have a long way to go yet!

Each bucket is in no particular order. I'll try to think of a more systematic way of cross-referencing with proposals and notes, but wanted to get the list out there.

I'll keep the list updated as we look at more feature ideas and change our minds about the relative importance.

Strong interest

  • Local functions (Proposal: #259) [currently in future branch]
  • Tuples (Proposal: #347)
  • Pattern matching, part I (type patterns in switch statements and is-expressions) (subset of Proposal: #206 Pattern Matching)
  • Ref locals and ref returns (Proposal: #118)
  • replace/original (part of generators) (Proposals: #5292, #5561)

Some interest

  • Binary literals (Proposal: #215) [currently in future branch]
  • Digit separators (Proposal: #216) [currently in future branch]
  • out var (Proposal: #6183)
  • Async main (Proposal: #7476)
  • address of static method for unsafe interop code (Do we have a proposal?)

Non-language


See also Language Feature Status (compiler team)

@erik-kallen

This comment has been minimized.

Show comment
Hide comment
@erik-kallen

erik-kallen Apr 21, 2015

What has happened to variable declaration expressions (which almost made it into C# 6) and the semicolon operator?

erik-kallen commented Apr 21, 2015

What has happened to variable declaration expressions (which almost made it into C# 6) and the semicolon operator?

@khellang

This comment has been minimized.

Show comment
Hide comment
@khellang

khellang Apr 21, 2015

Yeah. Declaration expressions was one feature I was really looking forward to in C# 6. I hope they're not dropped for good.

khellang commented Apr 21, 2015

Yeah. Declaration expressions was one feature I was really looking forward to in C# 6. I hope they're not dropped for good.

@SolalPirelli

This comment has been minimized.

Show comment
Hide comment
@SolalPirelli

SolalPirelli Apr 21, 2015

  • Supersedes

What does that point mean? Searching for "supersedes" in the issues only returns this one. :)

SolalPirelli commented Apr 21, 2015

  • Supersedes

What does that point mean? Searching for "supersedes" in the issues only returns this one. :)

@dsaf

This comment has been minimized.

Show comment
Hide comment
@dsaf

dsaf Apr 21, 2015

Is there any possibility that it will be released before the next version of Visual Studio? Waiting for two years to get all those awesome features would make me sad (although I have no idea about the complexity of the work).

PS: TypeScript seems to have lots of minor versions released.

dsaf commented Apr 21, 2015

Is there any possibility that it will be released before the next version of Visual Studio? Waiting for two years to get all those awesome features would make me sad (although I have no idea about the complexity of the work).

PS: TypeScript seems to have lots of minor versions released.

@stephentoub

This comment has been minimized.

Show comment
Hide comment
@stephentoub

stephentoub Apr 21, 2015

Member

@MadsTorgersen, I updated the description with some more proposal #s.

We should probably separate out from "Safe fixed-size buffers" the ability to use custom types (rather than the small set of primitives allowed today) in fixed-size buffers. That's separate from being able to use fixed-size buffers in safe structs, but we lumped them together when discussing how we probably wouldn't get to "safe fixed-size buffers".

What about the Nothing / DoesNotReturn feature?

Member

stephentoub commented Apr 21, 2015

@MadsTorgersen, I updated the description with some more proposal #s.

We should probably separate out from "Safe fixed-size buffers" the ability to use custom types (rather than the small set of primitives allowed today) in fixed-size buffers. That's separate from being able to use fixed-size buffers in safe structs, but we lumped them together when discussing how we probably wouldn't get to "safe fixed-size buffers".

What about the Nothing / DoesNotReturn feature?

@stepanbenes

This comment has been minimized.

Show comment
Hide comment
@stepanbenes

stepanbenes Apr 21, 2015

Deterministic disposal feature is mentioned both in "Some interest" bucket and "Probably never" bucket (as Destructible types). Having link to same proposal I suppose they both refer to the same thing.

stepanbenes commented Apr 21, 2015

Deterministic disposal feature is mentioned both in "Some interest" bucket and "Probably never" bucket (as Destructible types). Having link to same proposal I suppose they both refer to the same thing.

@stephentoub

This comment has been minimized.

Show comment
Hide comment
@stephentoub

stephentoub Apr 21, 2015

Member

@stepanbenes, I believe what Mads is trying to convey is that the specific solution called out in the proposal is something we don't intend to do as-is, but we would still like to do something to address the same problem area.

Member

stephentoub commented Apr 21, 2015

@stepanbenes, I believe what Mads is trying to convey is that the specific solution called out in the proposal is something we don't intend to do as-is, but we would still like to do something to address the same problem area.

@HaloFour

This comment has been minimized.

Show comment
Hide comment
@HaloFour

HaloFour Apr 21, 2015

The "Strong Interest" list is awesome. Pattern matching will be a huge addition to the language. I'm quite excited about async streams as well but I would hope that there is some room to consider IObservable<T> as well as a new IAsyncEnumerable<T>. I'd be happy to contribute towards that solution.

About static members in an interface, I believe that the CLR already permits that. Unless I'm misinterpreting what the feature entails. You also already have CLR support for enum and delegate generic constraints, but I could understand maybe wanting to lump that up with work to expose many more flavors of generic constraints.

HaloFour commented Apr 21, 2015

The "Strong Interest" list is awesome. Pattern matching will be a huge addition to the language. I'm quite excited about async streams as well but I would hope that there is some room to consider IObservable<T> as well as a new IAsyncEnumerable<T>. I'd be happy to contribute towards that solution.

About static members in an interface, I believe that the CLR already permits that. Unless I'm misinterpreting what the feature entails. You also already have CLR support for enum and delegate generic constraints, but I could understand maybe wanting to lump that up with work to expose many more flavors of generic constraints.

@MgSam

This comment has been minimized.

Show comment
Hide comment
@MgSam

MgSam Apr 21, 2015

Quite the list when you spell it all out!

I agree with nearly everything in the "Strong Interest" bucket. The "Some Interest" bucket has some good ones but also a few "meh" features listed, IMO, and is missing some good ones.

Off the top of my head:

MgSam commented Apr 21, 2015

Quite the list when you spell it all out!

I agree with nearly everything in the "Strong Interest" bucket. The "Some Interest" bucket has some good ones but also a few "meh" features listed, IMO, and is missing some good ones.

Off the top of my head:

@MgSam

This comment has been minimized.

Show comment
Hide comment
@MgSam

MgSam Apr 21, 2015

Also- I'm surprised readonly locals is in the "Some Interest" bucket. From the comments in the discussions it seems like there's strong interest in this, the only minor point of contention is whether to use let or val. I think this feature is just as useful, if not more useful, than the proposed non-nullability analyzers.

MgSam commented Apr 21, 2015

Also- I'm surprised readonly locals is in the "Some Interest" bucket. From the comments in the discussions it seems like there's strong interest in this, the only minor point of contention is whether to use let or val. I think this feature is just as useful, if not more useful, than the proposed non-nullability analyzers.

@MovGP0

This comment has been minimized.

Show comment
Hide comment
@MovGP0

MovGP0 Apr 22, 2015

I guess the features that would reduce developer errors most are:

  • non-nullable reference types
    • var! dog = new Dog();
  • immutable values
    • let age = 26;
    • immutable int age = 26;
  • immutable types
    • public immutable sealed class Dog { ... }
  • contracts
    • [Requires(...)] [Ensures(...)]
    • requires ..., ensures ...
  • units (C# 8? syntax?)

MovGP0 commented Apr 22, 2015

I guess the features that would reduce developer errors most are:

  • non-nullable reference types
    • var! dog = new Dog();
  • immutable values
    • let age = 26;
    • immutable int age = 26;
  • immutable types
    • public immutable sealed class Dog { ... }
  • contracts
    • [Requires(...)] [Ensures(...)]
    • requires ..., ensures ...
  • units (C# 8? syntax?)
@dsaf

This comment has been minimized.

Show comment
Hide comment
@dsaf

dsaf Apr 22, 2015

@MovGP0 In my experience in enterprise web dev the predominant majority of errors are made outside of C# code - JavaScript, HTML, CSS, SQL. I wish Spartan would just support C# and some lighter XAML natively... So I guess it makes sense to focus on the features that improve language expressiveness instead.

dsaf commented Apr 22, 2015

@MovGP0 In my experience in enterprise web dev the predominant majority of errors are made outside of C# code - JavaScript, HTML, CSS, SQL. I wish Spartan would just support C# and some lighter XAML natively... So I guess it makes sense to focus on the features that improve language expressiveness instead.

@Eirenarch

This comment has been minimized.

Show comment
Hide comment
@Eirenarch

Eirenarch Apr 22, 2015

Your strong interest list makes me very happy.

Eirenarch commented Apr 22, 2015

Your strong interest list makes me very happy.

@paavohuhtala

This comment has been minimized.

Show comment
Hide comment
@paavohuhtala

paavohuhtala Apr 22, 2015

@seanfreiburg How would that differ from the ??-operator?

paavohuhtala commented Apr 22, 2015

@seanfreiburg How would that differ from the ??-operator?

@JoshVarty

This comment has been minimized.

Show comment
Hide comment
@JoshVarty

JoshVarty Apr 23, 2015

Contributor

Any thoughts on #13 (Anonymous types that implement interfaces)?

Also, I think there would need to be a lot of thought given to declaration expressions before they should be "bucketed". The scoping issues from last time will need a lot of discussion. Personally, I still don't like any of the options there (especially the proposal to remove the shadowing restriction)

Contributor

JoshVarty commented Apr 23, 2015

Any thoughts on #13 (Anonymous types that implement interfaces)?

Also, I think there would need to be a lot of thought given to declaration expressions before they should be "bucketed". The scoping issues from last time will need a lot of discussion. Personally, I still don't like any of the options there (especially the proposal to remove the shadowing restriction)

@MovGP0

This comment has been minimized.

Show comment
Hide comment
@MovGP0

MovGP0 Apr 23, 2015

@dsaf well, yes and no. you are probably right that in other languages, developers make even more errors. still, F# developers make even less errors than C# developers. so it makes sense to make C# more like F#.

besides, XAML/C# in the browser was tried with Silverlight, but sadly unsuccessful. I bet the best chances are to use C#/F# to JavaScript compilers with HTML in the frontend.

MovGP0 commented Apr 23, 2015

@dsaf well, yes and no. you are probably right that in other languages, developers make even more errors. still, F# developers make even less errors than C# developers. so it makes sense to make C# more like F#.

besides, XAML/C# in the browser was tried with Silverlight, but sadly unsuccessful. I bet the best chances are to use C#/F# to JavaScript compilers with HTML in the frontend.

@amitsaini12345

This comment has been minimized.

Show comment
Hide comment
@amitsaini12345

amitsaini12345 Apr 23, 2015

I want To have the feature providing the runtime object defination will be changed. This will help of allowing the heavy objects of class. For e.g. if we do not need all the properties at a moment, we will use one rquired object of properties and no need to define separate classes and inheritance.

is it possible??.

If possible plz introduce such a feature. it will be great memory saving.

amitsaini12345 commented Apr 23, 2015

I want To have the feature providing the runtime object defination will be changed. This will help of allowing the heavy objects of class. For e.g. if we do not need all the properties at a moment, we will use one rquired object of properties and no need to define separate classes and inheritance.

is it possible??.

If possible plz introduce such a feature. it will be great memory saving.

@weitzhandler

This comment has been minimized.

Show comment
Hide comment
@weitzhandler

weitzhandler Apr 23, 2015

@dsaf #2136 (comment):

besides, XAML/C# in the browser was tried with Silverlight, but sadly unsuccessful. I bet the best chances are to use C#/F# to JavaScript compilers with HTML in the frontend.

Ditto! Unfortunately it doesn't look like MS is going to open their eyes about this any time soon.
With Apache Cordova and the like, this makes the whole even more attractive, having C# and XAML be the ultimate pair for Windows desktop, store, Android, OS X, iOS, and web.
Of all UI solutions XAML is the best. HTML-CSS-JS is a pain the ass, pardon my french.
There are many solutions about this out there, nothing free, nothing out-the-box.

weitzhandler commented Apr 23, 2015

@dsaf #2136 (comment):

besides, XAML/C# in the browser was tried with Silverlight, but sadly unsuccessful. I bet the best chances are to use C#/F# to JavaScript compilers with HTML in the frontend.

Ditto! Unfortunately it doesn't look like MS is going to open their eyes about this any time soon.
With Apache Cordova and the like, this makes the whole even more attractive, having C# and XAML be the ultimate pair for Windows desktop, store, Android, OS X, iOS, and web.
Of all UI solutions XAML is the best. HTML-CSS-JS is a pain the ass, pardon my french.
There are many solutions about this out there, nothing free, nothing out-the-box.

@jsphadetula

This comment has been minimized.

Show comment
Hide comment
@jsphadetula

jsphadetula Apr 23, 2015

What about support for auto generated object composition

jsphadetula commented Apr 23, 2015

What about support for auto generated object composition

@Eirenarch

This comment has been minimized.

Show comment
Hide comment
@Eirenarch

Eirenarch Apr 23, 2015

Sad to see declaration expressions and especially params IEnumerable go. Is there anything that was dropped in the last couple of months and where can I read about it? I checked the status page - https://roslyn.codeplex.com/wikipage?title=Language%20Feature%20Status&referringTitle=Documentation but it seems like features that were dropped were removed from the table instead of marked as dropped.

Eirenarch commented Apr 23, 2015

Sad to see declaration expressions and especially params IEnumerable go. Is there anything that was dropped in the last couple of months and where can I read about it? I checked the status page - https://roslyn.codeplex.com/wikipage?title=Language%20Feature%20Status&referringTitle=Documentation but it seems like features that were dropped were removed from the table instead of marked as dropped.

@srgloureiro

This comment has been minimized.

Show comment
Hide comment
@srgloureiro

srgloureiro Apr 23, 2015

Reference to constant parameters as in C++ would be a suggestion from me.

srgloureiro commented Apr 23, 2015

Reference to constant parameters as in C++ would be a suggestion from me.

@GoEddie

This comment has been minimized.

Show comment
Hide comment
@GoEddie

GoEddie Apr 23, 2015

Hey Mads - what about:

#102

Any idea where it fits?

GoEddie commented Apr 23, 2015

Hey Mads - what about:

#102

Any idea where it fits?

@Eirenarch

This comment has been minimized.

Show comment
Hide comment
@Eirenarch

Eirenarch Apr 23, 2015

@GoEddie for practical purposes this is covered by the Tuple proposal

Eirenarch commented Apr 23, 2015

@GoEddie for practical purposes this is covered by the Tuple proposal

@mcintyre321

This comment has been minimized.

Show comment
Hide comment
@mcintyre321

mcintyre321 Apr 23, 2015

I favour anonymous return types over the tuple proposal. Seems like a small change to achieve the same effect.

Also strong interest for Declaration expressions.

mcintyre321 commented Apr 23, 2015

I favour anonymous return types over the tuple proposal. Seems like a small change to achieve the same effect.

Also strong interest for Declaration expressions.

@GoEddie

This comment has been minimized.

Show comment
Hide comment
@GoEddie

GoEddie Apr 23, 2015

@Eirenarch thanks! I have updated 102 to point to the tuple proposal

GoEddie commented Apr 23, 2015

@Eirenarch thanks! I have updated 102 to point to the tuple proposal

@jcdickinson

This comment has been minimized.

Show comment
Hide comment
@jcdickinson

jcdickinson Apr 23, 2015

Shooting from the hip here.

Allow extension methods in non-static classes

Does allowing extension methods in interfaces make sense? Consider the current scenario with IEnumerable<T>, had interface extension methods been available the extension methods could have been placed in the interface saving marginally on namespace pollution (instead of the current situation with Enumerable). This would mean that interfaces would be one step closer to becoming mixins.

  • Implement as a native CLR feature - con: needs CLR support
  • Implement by automatically moving the methods into a compiler-generated class - con: bad language interopability

jcdickinson commented Apr 23, 2015

Shooting from the hip here.

Allow extension methods in non-static classes

Does allowing extension methods in interfaces make sense? Consider the current scenario with IEnumerable<T>, had interface extension methods been available the extension methods could have been placed in the interface saving marginally on namespace pollution (instead of the current situation with Enumerable). This would mean that interfaces would be one step closer to becoming mixins.

  • Implement as a native CLR feature - con: needs CLR support
  • Implement by automatically moving the methods into a compiler-generated class - con: bad language interopability
@iainholder

This comment has been minimized.

Show comment
Hide comment
@iainholder

iainholder Apr 23, 2015

I'd be interested to know why INPC support is in the probably never bucket. Is that because it's
a) hard
b) easy but why build in support for something that already has a few well known patterns or
c) INPC will be irrelevant by the time C#7 comes out?

iainholder commented Apr 23, 2015

I'd be interested to know why INPC support is in the probably never bucket. Is that because it's
a) hard
b) easy but why build in support for something that already has a few well known patterns or
c) INPC will be irrelevant by the time C#7 comes out?

@HaloFour

This comment has been minimized.

Show comment
Hide comment
@HaloFour

HaloFour Apr 23, 2015

CLR/IL allows static members in interfaces. Might be useful for defining
extension methods close to the extended interface or for virtual
extension methods assuming the CLR could be changed to add a vtable slot
that would default to that static method.

Still, removing the limitation that extension methods be defined on static
classes would be helpful in eliminating the need for additional cases to
support some API and I welcome it.
On Apr 23, 2015 8:03 AM, "Jonathan Dickinson" notifications@github.com
wrote:

Shooting from the hip here.

Allow extension methods in non-static classes

Does allowing extension methods in interfaces make sense? Consider the
current scenario with IEnumerable, had interface extension methods
been available the extension methods could have been placed in the
interface saving marginally on namespace pollution (instead of the current
situation with Enumerable). This would mean that interfaces would be one
step closer to becoming mixins.

  • Implement as a native CLR feature - con: needs CLR support
  • Implement by automatically moving the methods into a
    compiler-generated class - con: bad language interopability


Reply to this email directly or view it on GitHub
#2136 (comment).

HaloFour commented Apr 23, 2015

CLR/IL allows static members in interfaces. Might be useful for defining
extension methods close to the extended interface or for virtual
extension methods assuming the CLR could be changed to add a vtable slot
that would default to that static method.

Still, removing the limitation that extension methods be defined on static
classes would be helpful in eliminating the need for additional cases to
support some API and I welcome it.
On Apr 23, 2015 8:03 AM, "Jonathan Dickinson" notifications@github.com
wrote:

Shooting from the hip here.

Allow extension methods in non-static classes

Does allowing extension methods in interfaces make sense? Consider the
current scenario with IEnumerable, had interface extension methods
been available the extension methods could have been placed in the
interface saving marginally on namespace pollution (instead of the current
situation with Enumerable). This would mean that interfaces would be one
step closer to becoming mixins.

  • Implement as a native CLR feature - con: needs CLR support
  • Implement by automatically moving the methods into a
    compiler-generated class - con: bad language interopability


Reply to this email directly or view it on GitHub
#2136 (comment).

@ufcpp

This comment has been minimized.

Show comment
Hide comment
@ufcpp

ufcpp Apr 23, 2015

@iainholder INPC is listed in #1677 as 'too specific; metaprogramming?'

ufcpp commented Apr 23, 2015

@iainholder INPC is listed in #1677 as 'too specific; metaprogramming?'

@bencyoung

This comment has been minimized.

Show comment
Hide comment
@bencyoung

bencyoung Apr 23, 2015

One thing that would be extremely beneficial for Linq performance would be IExactSizedEnumerable and IMaxSizedEnumerable or similar. Often you have chains of operations of Linq operations on a container and the fact that an exact result size is expected is lost. If the size can be preserved then the amount of allocation and copying that takes place in ToArray, ToList etc can be minimised.

Python does this using a property called length_hint https://www.python.org/dev/peps/pep-0424/

bencyoung commented Apr 23, 2015

One thing that would be extremely beneficial for Linq performance would be IExactSizedEnumerable and IMaxSizedEnumerable or similar. Often you have chains of operations of Linq operations on a container and the fact that an exact result size is expected is lost. If the size can be preserved then the amount of allocation and copying that takes place in ToArray, ToList etc can be minimised.

Python does this using a property called length_hint https://www.python.org/dev/peps/pep-0424/

@jcdickinson

This comment has been minimized.

Show comment
Hide comment
@jcdickinson

jcdickinson Apr 23, 2015

IExactSizedEnumerable = IReadOnlyCollection.

jcdickinson commented Apr 23, 2015

IExactSizedEnumerable = IReadOnlyCollection.

@BrandesEric

This comment has been minimized.

Show comment
Hide comment
@BrandesEric

BrandesEric Apr 23, 2015

+1 for the Tuple proposal. Multiple return values is really the only remaining feature I really want. Given what I feel is the community's general distaste for Tuples, perhaps it would be worth calling the proposal "Multiple return types (Tuples)" or something :)

BrandesEric commented Apr 23, 2015

+1 for the Tuple proposal. Multiple return values is really the only remaining feature I really want. Given what I feel is the community's general distaste for Tuples, perhaps it would be worth calling the proposal "Multiple return types (Tuples)" or something :)

@weitzhandler

This comment has been minimized.

Show comment
Hide comment
@weitzhandler

weitzhandler Apr 23, 2015

#2136 (comment)

I'd be interested to know why INPC support is in the probably never bucket.

I believe because it's too technology specific. There are no need for INPC in ASP.NET or console apps for example.
With the introduction of the nameof operator, INPC will become much nicer and safer anyway.

weitzhandler commented Apr 23, 2015

#2136 (comment)

I'd be interested to know why INPC support is in the probably never bucket.

I believe because it's too technology specific. There are no need for INPC in ASP.NET or console apps for example.
With the introduction of the nameof operator, INPC will become much nicer and safer anyway.

@NikChao

This comment has been minimized.

Show comment
Hide comment
@NikChao

NikChao Dec 7, 2016

Request: Bidirectional mapping feature:

At the moment if I want to map one object to another and back I'll write mappers as follows

public ObjectOne ToObjectOne(ObjectTwo obj)
    => new ObjectOne
    {
        Id = obj.Id,
        Name = obj.Name
        //etc
    }

public ObjectTwo ToObjectTwo(ObjectOne obj)
    => new ObjectTwo
    {
        Id = obj.Id,
        Name = obj.Name
        //etc
    }

I propose a bidirectional mapping feature which would use:

public ObjectOne ToObjectOne <=> ObjectTwo ToObjectTwo
{
   ObjectOne.Id = ObjectTwo.Id,
   //etc.
}

In my imagination, this syntax would compile to implicitly define the ToObjectOne and ToObjectTwo methods above.

#15735

NikChao commented Dec 7, 2016

Request: Bidirectional mapping feature:

At the moment if I want to map one object to another and back I'll write mappers as follows

public ObjectOne ToObjectOne(ObjectTwo obj)
    => new ObjectOne
    {
        Id = obj.Id,
        Name = obj.Name
        //etc
    }

public ObjectTwo ToObjectTwo(ObjectOne obj)
    => new ObjectTwo
    {
        Id = obj.Id,
        Name = obj.Name
        //etc
    }

I propose a bidirectional mapping feature which would use:

public ObjectOne ToObjectOne <=> ObjectTwo ToObjectTwo
{
   ObjectOne.Id = ObjectTwo.Id,
   //etc.
}

In my imagination, this syntax would compile to implicitly define the ToObjectOne and ToObjectTwo methods above.

#15735

@MovGP0

This comment has been minimized.

Show comment
Hide comment
@MovGP0

MovGP0 Dec 7, 2016

@NikChao I am unsure why you write such mappers in the first place. What advantage would your mapping feature have over AutoMapper?

MovGP0 commented Dec 7, 2016

@NikChao I am unsure why you write such mappers in the first place. What advantage would your mapping feature have over AutoMapper?

@NikChao

This comment has been minimized.

Show comment
Hide comment
@NikChao

NikChao Dec 7, 2016

@MovGP0 Used to use Automapper but it turns out it tends to perform quite poorly (slowly) when you begin to map high numbers of objects, so now I tend to write my own.

NikChao commented Dec 7, 2016

@MovGP0 Used to use Automapper but it turns out it tends to perform quite poorly (slowly) when you begin to map high numbers of objects, so now I tend to write my own.

@realbart

This comment has been minimized.

Show comment
Hide comment
@realbart

realbart Dec 7, 2016

@NikChao what happens if the mapping uses methods, read-only properties or other more complex properties?

public static ObjectTwo ToObjectTwo(this ObjectOne obj) 
{ 
    return obj == null
    ? default(ObjTwo)
     : new ObjectTwo
    {
        Id = obj.Id,
        Name = obj.ToString(),
        FirstChild = obj.Children.FirstOrDefault().ToChildTwo()
        //etc
    }
}

(I often use Expression<Func<ObjectOne, ObjectTwo>>. Ik can cache the compiled result, to prevent a performance impact, but I can also quite easily feed this to linq like linq to EF and linq to SQL.

@MovGP0: even though Automapper has made some great performance improvments, I still hate it. Instead of compilation errors, you only see them at unit test time. Renaming a property breaks everything.
@NikChao , @MovGP0 you could easily create T4 templates that generate the two way conversion for you. Then you'll have compile time validation AND you prevent code duplication.

realbart commented Dec 7, 2016

@NikChao what happens if the mapping uses methods, read-only properties or other more complex properties?

public static ObjectTwo ToObjectTwo(this ObjectOne obj) 
{ 
    return obj == null
    ? default(ObjTwo)
     : new ObjectTwo
    {
        Id = obj.Id,
        Name = obj.ToString(),
        FirstChild = obj.Children.FirstOrDefault().ToChildTwo()
        //etc
    }
}

(I often use Expression<Func<ObjectOne, ObjectTwo>>. Ik can cache the compiled result, to prevent a performance impact, but I can also quite easily feed this to linq like linq to EF and linq to SQL.

@MovGP0: even though Automapper has made some great performance improvments, I still hate it. Instead of compilation errors, you only see them at unit test time. Renaming a property breaks everything.
@NikChao , @MovGP0 you could easily create T4 templates that generate the two way conversion for you. Then you'll have compile time validation AND you prevent code duplication.

@NikChao

This comment has been minimized.

Show comment
Hide comment
@NikChao

NikChao Dec 7, 2016

@realbart Hmm, perhaps read-only's only get mapped one way in this case and more complex Objects should still be able to be mapped bidirectionally. As for T4 templates, they are nice, but I see this as a syntactically easier approach for this sort of mapping.

NikChao commented Dec 7, 2016

@realbart Hmm, perhaps read-only's only get mapped one way in this case and more complex Objects should still be able to be mapped bidirectionally. As for T4 templates, they are nice, but I see this as a syntactically easier approach for this sort of mapping.

@HaloFour

This comment has been minimized.

Show comment
Hide comment
@HaloFour

HaloFour Dec 7, 2016

@NikChao

Sounds like something that would be easily accomplished by source generators. Like T4 that would inject additional source into the project, but it would be effectively transparent. Either way, you should open a new issue for any proposals.

HaloFour commented Dec 7, 2016

@NikChao

Sounds like something that would be easily accomplished by source generators. Like T4 that would inject additional source into the project, but it would be effectively transparent. Either way, you should open a new issue for any proposals.

@MovGP0

This comment has been minimized.

Show comment
Hide comment
@MovGP0

MovGP0 Dec 28, 2016

@gdefraiteur seems like you are reinventing the squared wheel. use the nameof operator and dictionary initializers.

MovGP0 commented Dec 28, 2016

@gdefraiteur seems like you are reinventing the squared wheel. use the nameof operator and dictionary initializers.

@gdefraiteur

This comment has been minimized.

Show comment
Hide comment
@gdefraiteur

gdefraiteur Jan 1, 2017

and what about being able to use out or ref optional parameters?

gdefraiteur commented Jan 1, 2017

and what about being able to use out or ref optional parameters?

@gafter

This comment has been minimized.

Show comment
Hide comment
@gafter

gafter Jan 1, 2017

Member

@gdefraiteur There is nothing in C# 7 about optional out or ref parameters.

Member

gafter commented Jan 1, 2017

@gdefraiteur There is nothing in C# 7 about optional out or ref parameters.

@gdefraiteur

This comment has been minimized.

Show comment
Hide comment
@gdefraiteur

gdefraiteur Jan 2, 2017

@gafter
Thats why i make the proposal no?

gdefraiteur commented Jan 2, 2017

@gafter
Thats why i make the proposal no?

@HaloFour

This comment has been minimized.

Show comment
Hide comment
@HaloFour

HaloFour Jan 2, 2017

@gdefraiteur

If that's what you want to propose I suggest creating a new issue. These comments aren't tracked for consideration. There is already #186, but I don't know that I see a proposal dealing with ref parameters. It's probably very unlikely for anything new to be considered for C# 7.0 at this point, but maybe a release after that.

HaloFour commented Jan 2, 2017

@gdefraiteur

If that's what you want to propose I suggest creating a new issue. These comments aren't tracked for consideration. There is already #186, but I don't know that I see a proposal dealing with ref parameters. It's probably very unlikely for anything new to be considered for C# 7.0 at this point, but maybe a release after that.

@gafter

This comment has been minimized.

Show comment
Hide comment
@gafter

gafter Jan 2, 2017

Member

@gdefraiteur we are no longer soliciting ideas for new features for C# 7.

Member

gafter commented Jan 2, 2017

@gdefraiteur we are no longer soliciting ideas for new features for C# 7.

@yaakov-h

This comment has been minimized.

Show comment
Hide comment
@yaakov-h

yaakov-h Jan 2, 2017

@gafter Started on a C# 8 list yet?

yaakov-h commented Jan 2, 2017

@gafter Started on a C# 8 list yet?

@gafter

This comment has been minimized.

Show comment
Hide comment
@gafter

gafter Jan 2, 2017

Member

@yaakov-h Not really, though if we did have a corresponding list for C# 8, that would not be the place to make proposals.

Member

gafter commented Jan 2, 2017

@yaakov-h Not really, though if we did have a corresponding list for C# 8, that would not be the place to make proposals.

@gulshan

This comment has been minimized.

Show comment
Hide comment

gulshan commented Jan 5, 2017

@gafter Is https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md updated to reflect the current plan/roadmap/status?

@gafter

This comment has been minimized.

Show comment
Hide comment
@gafter

gafter Jan 5, 2017

Member

We don't yet have plans for future releases.

Member

gafter commented Jan 5, 2017

We don't yet have plans for future releases.

@ygc369

This comment has been minimized.

Show comment
Hide comment
@ygc369

ygc369 Feb 6, 2017

@gafter
Have roadmap for C#8.0 now?

ygc369 commented Feb 6, 2017

@gafter
Have roadmap for C#8.0 now?

@jnm2

This comment has been minimized.

Show comment
Hide comment
@jnm2

jnm2 Feb 6, 2017

Contributor

@ygc369 I'd not expect that until C# 7 is shipped. They're pretty busy. =)

Contributor

jnm2 commented Feb 6, 2017

@ygc369 I'd not expect that until C# 7 is shipped. They're pretty busy. =)

@paulomorgado

This comment has been minimized.

Show comment
Hide comment
@paulomorgado

paulomorgado Feb 7, 2017

And C# 7.1. And C# 7.2.....

paulomorgado commented Feb 7, 2017

And C# 7.1. And C# 7.2.....

@ygc369

This comment has been minimized.

Show comment
Hide comment
@ygc369

ygc369 Feb 7, 2017

We've discussed so many ways to improve performance, but C#7 only implement few of them. This is very disappointing. C# is a "beautiful" language, the only lack is performance, especially about GC.

ygc369 commented Feb 7, 2017

We've discussed so many ways to improve performance, but C#7 only implement few of them. This is very disappointing. C# is a "beautiful" language, the only lack is performance, especially about GC.

@marchy

This comment has been minimized.

Show comment
Hide comment
@marchy

marchy Feb 7, 2017

GC is a very outdated concept. .NET needs to move to Automatic Reference Counting (as did Objective-C / Swift). It has all the programming simplicity and safety benefits while also having immediate deallocation / performance benefits.

It's hard to say whether C# will EVER be able to move over to a different/faster memory model, whether GC is embedded far too deep to ever be replaced. Wouldn't bank on it.

marchy commented Feb 7, 2017

GC is a very outdated concept. .NET needs to move to Automatic Reference Counting (as did Objective-C / Swift). It has all the programming simplicity and safety benefits while also having immediate deallocation / performance benefits.

It's hard to say whether C# will EVER be able to move over to a different/faster memory model, whether GC is embedded far too deep to ever be replaced. Wouldn't bank on it.

@vladd

This comment has been minimized.

Show comment
Hide comment
@vladd

vladd Feb 7, 2017

@marchy Been there, done that. ARC means manual reference cycle breaking, and a lot of attention to object lifetime everywhere. Especially nasty is this with lambdas ("week self" for access to properties in lambdas, anyone wants?). This will silently make virtually all the existing code leaky and therefore invalid. I bet that the "improvement" you are proposing will not be accepted by both the language design team and community.

vladd commented Feb 7, 2017

@marchy Been there, done that. ARC means manual reference cycle breaking, and a lot of attention to object lifetime everywhere. Especially nasty is this with lambdas ("week self" for access to properties in lambdas, anyone wants?). This will silently make virtually all the existing code leaky and therefore invalid. I bet that the "improvement" you are proposing will not be accepted by both the language design team and community.

@marchy

This comment has been minimized.

Show comment
Hide comment
@marchy

marchy Feb 7, 2017

@vladd thanks a lot for that. Yes, there does mean people need awareness of memory. Deciding which component affects which other one is extremely important and does NOT go away in GC scenarios. We spun up specialized, senior teams on C# to chase memory leaks on .NET, particularly because they are that much more hidden and hard to discover when awareness by teams is not had at all (event subscriptions, callback patterns that hold strong references to object).

"weak self" is indeed annoying and not the most elegant solution (perhaps weak should be default for lambdas on Swift), but overall for the most part it DOES just works, while coming with none of the performance & memory demands that GC-based systems provide.

There's a reason Apple deprecated garbage collection on the mac after ARC came into the picture.
Developers aren't schoolchildren... it's a level of balance between simplicity that the .NET community can absolutely can handle. NOTE that I am not making a case for MANUAL reference counting (C++ and pre-ARC Obj-C days).

marchy commented Feb 7, 2017

@vladd thanks a lot for that. Yes, there does mean people need awareness of memory. Deciding which component affects which other one is extremely important and does NOT go away in GC scenarios. We spun up specialized, senior teams on C# to chase memory leaks on .NET, particularly because they are that much more hidden and hard to discover when awareness by teams is not had at all (event subscriptions, callback patterns that hold strong references to object).

"weak self" is indeed annoying and not the most elegant solution (perhaps weak should be default for lambdas on Swift), but overall for the most part it DOES just works, while coming with none of the performance & memory demands that GC-based systems provide.

There's a reason Apple deprecated garbage collection on the mac after ARC came into the picture.
Developers aren't schoolchildren... it's a level of balance between simplicity that the .NET community can absolutely can handle. NOTE that I am not making a case for MANUAL reference counting (C++ and pre-ARC Obj-C days).

@SolalPirelli

This comment has been minimized.

Show comment
Hide comment
@SolalPirelli

SolalPirelli Feb 7, 2017

@marchy You were also the one saying that C# would die if non-nullability wasn't in C#7. Asking the C# language designers to make enormous breaking changes (in the runtime rather than the language, even!) is pointless. Please look around yourself, read others' opinions, and accept the fact that you're very isolated in your position.

SolalPirelli commented Feb 7, 2017

@marchy You were also the one saying that C# would die if non-nullability wasn't in C#7. Asking the C# language designers to make enormous breaking changes (in the runtime rather than the language, even!) is pointless. Please look around yourself, read others' opinions, and accept the fact that you're very isolated in your position.

@vladd

This comment has been minimized.

Show comment
Hide comment
@vladd

vladd Feb 7, 2017

@marchy For me, most of time I don't really care about exact object lifetimes.

The same way as I don't care about alignment, about exact physical representation of lambdas, about overhead of storing the string length along with strings, about special magic which delegate makes to turn an instance method into something which looks like a free function, about exact shape of the state machine which compiler creates behind the scene for async methods and about a ton of different other technical details. I don't want the language to force me into considering them for each and every line of code, this would mean that my productivity as language user would drop to the native language level.

If controlling some of the details matters in some special case, I do the manual solution, the language allows me that. (Or in the rare event when it doesn't allow, I implement a part of the program in native code.)

(And by the way, ARC is not so innocent. Consider leaving a UI page which usually involves killing the last reference which holds a large object tree in memory—this will make the tree be destructed and run the destruction logic synchronously. This is certainly not better than GC slowly chewing on the tree in background.)

vladd commented Feb 7, 2017

@marchy For me, most of time I don't really care about exact object lifetimes.

The same way as I don't care about alignment, about exact physical representation of lambdas, about overhead of storing the string length along with strings, about special magic which delegate makes to turn an instance method into something which looks like a free function, about exact shape of the state machine which compiler creates behind the scene for async methods and about a ton of different other technical details. I don't want the language to force me into considering them for each and every line of code, this would mean that my productivity as language user would drop to the native language level.

If controlling some of the details matters in some special case, I do the manual solution, the language allows me that. (Or in the rare event when it doesn't allow, I implement a part of the program in native code.)

(And by the way, ARC is not so innocent. Consider leaving a UI page which usually involves killing the last reference which holds a large object tree in memory—this will make the tree be destructed and run the destruction logic synchronously. This is certainly not better than GC slowly chewing on the tree in background.)

@timgoodman

This comment has been minimized.

Show comment
Hide comment
@timgoodman

timgoodman Feb 7, 2017

@marchy A generational tracing GC is performant enough for the vast majority of cases in which C# is being used today (or Java for that matter), as evidenced by the fact that these languages continue to be among the most widely used.  So I really doubt the .NET team is going to make the huge investment to switch to a different form of memory management any time in the foreseeable future. Personally, I'd prefer that performance improvements are focused on the lower hanging fruit that will benefit a much wider range of .NET developers, such as making LINQ (at least LINQ-to-objects) more performant with aggressive in-lining, stack allocation, loop fusion, etc.

timgoodman commented Feb 7, 2017

@marchy A generational tracing GC is performant enough for the vast majority of cases in which C# is being used today (or Java for that matter), as evidenced by the fact that these languages continue to be among the most widely used.  So I really doubt the .NET team is going to make the huge investment to switch to a different form of memory management any time in the foreseeable future. Personally, I'd prefer that performance improvements are focused on the lower hanging fruit that will benefit a much wider range of .NET developers, such as making LINQ (at least LINQ-to-objects) more performant with aggressive in-lining, stack allocation, loop fusion, etc.

@ygc369

This comment has been minimized.

Show comment
Hide comment
@ygc369

ygc369 Feb 8, 2017

@timgoodman
@marchy
@vladd
@SolalPirelli
@gafter
@HaloFour
I think that GC should not be replaced, no one wants breaking changes. But ARC should be introduced into C# as an alternative memory management, it can work together with GC. For example, ARC collect most of garbage objects that are not in ref cycle, GC collect the left garbage objects in ref cycle. For default, CLR should use GC as before, no breaking change. But if someone wants to use ARC in some cases, he must use special syntax to tell the compiler or CLR.
For example:
var gc_obj = new object(); // gc_obj should be managed by GC
var arc_obj = arc_new object(); // arc_obj should be managed by ARC
In above example, I use syntax "arc_new" to alloc a new object managed by ARC. Of course, it only means that it can be collected by ARC, but it can also be collected by GC if it's in ref cycle.
I think this idea would perfectly resolve the conflict between GC and ARC.

ygc369 commented Feb 8, 2017

@timgoodman
@marchy
@vladd
@SolalPirelli
@gafter
@HaloFour
I think that GC should not be replaced, no one wants breaking changes. But ARC should be introduced into C# as an alternative memory management, it can work together with GC. For example, ARC collect most of garbage objects that are not in ref cycle, GC collect the left garbage objects in ref cycle. For default, CLR should use GC as before, no breaking change. But if someone wants to use ARC in some cases, he must use special syntax to tell the compiler or CLR.
For example:
var gc_obj = new object(); // gc_obj should be managed by GC
var arc_obj = arc_new object(); // arc_obj should be managed by ARC
In above example, I use syntax "arc_new" to alloc a new object managed by ARC. Of course, it only means that it can be collected by ARC, but it can also be collected by GC if it's in ref cycle.
I think this idea would perfectly resolve the conflict between GC and ARC.

@ygc369

This comment has been minimized.

Show comment
Hide comment
@ygc369

ygc369 Feb 8, 2017

@timgoodman
@gafter
@HaloFour
@MadsTorgersen
@erik-kallen
@khellang
@SolalPirelli
@dsaf
@vladd
I have many other ideas about GC optimization:

  1. Optimization for LOH: dotnet/coreclr#555
  2. Class or fixed array safely embedded in other class: #2097
  3. Optimization for weak reference: #2171
  4. Stack allocation: dotnet/coreclr#1784
  5. Other small optimizations of GC:
    dotnet/coreclr#1856
    and
    dotnet/coreclr#1855

I hope more people are interested in above ideas.

ygc369 commented Feb 8, 2017

@timgoodman
@gafter
@HaloFour
@MadsTorgersen
@erik-kallen
@khellang
@SolalPirelli
@dsaf
@vladd
I have many other ideas about GC optimization:

  1. Optimization for LOH: dotnet/coreclr#555
  2. Class or fixed array safely embedded in other class: #2097
  3. Optimization for weak reference: #2171
  4. Stack allocation: dotnet/coreclr#1784
  5. Other small optimizations of GC:
    dotnet/coreclr#1856
    and
    dotnet/coreclr#1855

I hope more people are interested in above ideas.

@FrankHB

This comment has been minimized.

Show comment
Hide comment
@FrankHB

FrankHB Feb 8, 2017

@marchy Reference counting is as old as GC (both were from 1959). GC is not outdated for specific use like converting too large free memory to extra throughput in a system (and mostly only when the latency is not cared about); it is just an optimization being abused.

Your argument about awareness still seems too weak. The fact is, there are always limited resources available to solve problems by concrete machines in reality, so people should know how to manage the onwership of resources in their solution of problems to make it logically consistent (e.g. before coding, keeping the design without any suspicous loop of dependencies to break at runtime, unless they are introduced by input of the solution). Otherwise, the solutions are inadquately designed because part of problem-specific work derserved to be solved is missing. Note there is no known "heuristic" algorithm which can beat well-trained humans for specific purpose (to resolve such inconsistency) in general, since there is no one-thing-fit-all way to tell the implementation the precise intention of the problems being solved and to guarantee it optimzed. Further, memory is just one kind of such limited resources.

I'd also note automatic resource management (RAII/RRID idiom) in C++ comes far earlier than ObjC. Notably, it is not only effective on memory; it can work on other resources like locks and database connections. And it needs no compiler magic.

FrankHB commented Feb 8, 2017

@marchy Reference counting is as old as GC (both were from 1959). GC is not outdated for specific use like converting too large free memory to extra throughput in a system (and mostly only when the latency is not cared about); it is just an optimization being abused.

Your argument about awareness still seems too weak. The fact is, there are always limited resources available to solve problems by concrete machines in reality, so people should know how to manage the onwership of resources in their solution of problems to make it logically consistent (e.g. before coding, keeping the design without any suspicous loop of dependencies to break at runtime, unless they are introduced by input of the solution). Otherwise, the solutions are inadquately designed because part of problem-specific work derserved to be solved is missing. Note there is no known "heuristic" algorithm which can beat well-trained humans for specific purpose (to resolve such inconsistency) in general, since there is no one-thing-fit-all way to tell the implementation the precise intention of the problems being solved and to guarantee it optimzed. Further, memory is just one kind of such limited resources.

I'd also note automatic resource management (RAII/RRID idiom) in C++ comes far earlier than ObjC. Notably, it is not only effective on memory; it can work on other resources like locks and database connections. And it needs no compiler magic.

@FrankHB

This comment has been minimized.

Show comment
Hide comment
@FrankHB

FrankHB Feb 8, 2017

@vladd The lifetime of particular objects may be trivial like alignments as implementation details, but the overall results are not similar, e.g. resources may be difficult to reclaim if you know nothing about lifetimes, which can be treated as plain leaks by users.

I think being ignorant of any object lifetime by default can only work in speicific scenes, which mostly need only several DSLs rather than a general-purposed language. Otherwise, it is generally infeasible and methodologically ill-formed, unless you don't care end-users' need: because you can't estimate how many leaks the end-users can tolerate. And even all industrial users can allow this silently, system performance (also the cost on hardware) is already unnecessarily wasted a lot.

To tweak the process about how to release the resources is another story after you can guarantee the deterministic behavior in time.

FrankHB commented Feb 8, 2017

@vladd The lifetime of particular objects may be trivial like alignments as implementation details, but the overall results are not similar, e.g. resources may be difficult to reclaim if you know nothing about lifetimes, which can be treated as plain leaks by users.

I think being ignorant of any object lifetime by default can only work in speicific scenes, which mostly need only several DSLs rather than a general-purposed language. Otherwise, it is generally infeasible and methodologically ill-formed, unless you don't care end-users' need: because you can't estimate how many leaks the end-users can tolerate. And even all industrial users can allow this silently, system performance (also the cost on hardware) is already unnecessarily wasted a lot.

To tweak the process about how to release the resources is another story after you can guarantee the deterministic behavior in time.

@FrankHB

This comment has been minimized.

Show comment
Hide comment
@FrankHB

FrankHB Feb 8, 2017

An addition note on language design: modern Lisp dialects (esp. Scheme family) has better reasons to mandate unlimited extent of objects because a) objects are not bound to probable side effects on release (which is also true for many other languages) and b) both proper tail call optimization and undelimited first-class continuation are needed as killer features.

I don't see any other theoretical reason to make unbounded indeterminsitic mechanism like GC required by default in a general-purposed language.

FrankHB commented Feb 8, 2017

An addition note on language design: modern Lisp dialects (esp. Scheme family) has better reasons to mandate unlimited extent of objects because a) objects are not bound to probable side effects on release (which is also true for many other languages) and b) both proper tail call optimization and undelimited first-class continuation are needed as killer features.

I don't see any other theoretical reason to make unbounded indeterminsitic mechanism like GC required by default in a general-purposed language.

@ygc369

This comment has been minimized.

Show comment
Hide comment
@ygc369

ygc369 Feb 8, 2017

@FrankHB
写了这么多啊,大概看了下,你是支持引用计数的,对吧?

ygc369 commented Feb 8, 2017

@FrankHB
写了这么多啊,大概看了下,你是支持引用计数的,对吧?

@dsaf

This comment has been minimized.

Show comment
Hide comment
@dsaf

dsaf Feb 8, 2017

@ygc369 what kind of stuff are you building if you are that passionate about GC optimization? Anyway I am waiting for a production-ready C# 7 release before being interested in any further features.

dsaf commented Feb 8, 2017

@ygc369 what kind of stuff are you building if you are that passionate about GC optimization? Anyway I am waiting for a production-ready C# 7 release before being interested in any further features.

@Joe4evr

This comment has been minimized.

Show comment
Hide comment
@Joe4evr

Joe4evr Feb 8, 2017

Developers aren't schoolchildren...

The amount of script kiddies I (and a few others) deal with on helping to use Discord.Net says otherwise. Some even come in with zero understanding of programming in general, thinking that using a relatively complex lib to make a bot is a good Programming 101 exercise.

Joe4evr commented Feb 8, 2017

Developers aren't schoolchildren...

The amount of script kiddies I (and a few others) deal with on helping to use Discord.Net says otherwise. Some even come in with zero understanding of programming in general, thinking that using a relatively complex lib to make a bot is a good Programming 101 exercise.

@FrankHB

This comment has been minimized.

Show comment
Hide comment
@FrankHB

FrankHB Feb 8, 2017

@ygc369 怎么突然有了一股钦定的感觉呢……

实际上我没直接提的是大部分场合引用计数都用不上。

FrankHB commented Feb 8, 2017

@ygc369 怎么突然有了一股钦定的感觉呢……

实际上我没直接提的是大部分场合引用计数都用不上。

@gafter

This comment has been minimized.

Show comment
Hide comment
@gafter

gafter Feb 23, 2017

Member

The list of features for C# 7 can be found here in the csharplang repo.

We're using that repository for language proposals and discussion now.

Member

gafter commented Feb 23, 2017

The list of features for C# 7 can be found here in the csharplang repo.

We're using that repository for language proposals and discussion now.

@gafter gafter closed this Feb 23, 2017

@lemadane

This comment has been minimized.

Show comment
Hide comment
@lemadane

lemadane Dec 2, 2017

I would like to add the alternative keywords:

  1. not for ! so:

    if (not isDone) { ... }
    

instead of:

    if(!isDone) { ... }
  1. and for && so

    if(isDone and isPassed) { ... }
    

instead of:

      if(isDone && isPassed) { ... }
  1. or for ||

  2. nor for !(a || b) operation so

     if(isDone nor isPassed) { ... }
    

instead of:

    if(!(isDone || isPassed)) { ... }
  1. nand for !(a && b) operation so

    while(isDone nand isPassed) { ... }
    

instead of:

   while(!(isDone && isPassed)) { ... }
  1. extend const keyword for immutable variables:

    const testRunner = new TestRunner();
    

instead of:

    var testRunner = new TestRunner();
  1. make ; optional, may be used it when separating 2 statements in one line.

  2. true/false for truthy and falsy:

     if(false customerList) { throw new Exception("Customer list cannot be null of empty.") }
    

lemadane commented Dec 2, 2017

I would like to add the alternative keywords:

  1. not for ! so:

    if (not isDone) { ... }
    

instead of:

    if(!isDone) { ... }
  1. and for && so

    if(isDone and isPassed) { ... }
    

instead of:

      if(isDone && isPassed) { ... }
  1. or for ||

  2. nor for !(a || b) operation so

     if(isDone nor isPassed) { ... }
    

instead of:

    if(!(isDone || isPassed)) { ... }
  1. nand for !(a && b) operation so

    while(isDone nand isPassed) { ... }
    

instead of:

   while(!(isDone && isPassed)) { ... }
  1. extend const keyword for immutable variables:

    const testRunner = new TestRunner();
    

instead of:

    var testRunner = new TestRunner();
  1. make ; optional, may be used it when separating 2 statements in one line.

  2. true/false for truthy and falsy:

     if(false customerList) { throw new Exception("Customer list cannot be null of empty.") }
    
@gafter

This comment has been minimized.

Show comment
Hide comment
@gafter

gafter Dec 2, 2017

Member

@lemadane commenting on a closed issue is not likely to get anything done. I suggest you look to see if there are any issues suggesting any of these things, and comment there, or open a new issue otherwise.

Member

gafter commented Dec 2, 2017

@lemadane commenting on a closed issue is not likely to get anything done. I suggest you look to see if there are any issues suggesting any of these things, and comment there, or open a new issue otherwise.

@jnm2

This comment has been minimized.

Show comment
Hide comment
@jnm2

jnm2 Dec 2, 2017

Contributor

@lemadane I do think there are existing issues covering most of your suggestions.

Contributor

jnm2 commented Dec 2, 2017

@lemadane I do think there are existing issues covering most of your suggestions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment