Skip to content
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
Closed

C# 7 Work List of Features #2136

MadsTorgersen opened this issue Apr 21, 2015 · 463 comments

Comments

@MadsTorgersen
Copy link
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

Some interest

Non-language


See also Language Feature Status (compiler team)

@erik-kallen
Copy link

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

@khellang
Copy link
Member

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

@SolalPirelli
Copy link

  • Supersedes

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

@dsaf
Copy link

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
Copy link
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?

@stepanbenes
Copy link

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
Copy link
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.

@HaloFour
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

Your strong interest list makes me very happy.

@paavohuhtala
Copy link

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

@JoshVarty
Copy link
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)

@MovGP0
Copy link

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
Copy link

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
Copy link
Contributor

@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
Copy link

What about support for auto generated object composition

@Eirenarch
Copy link

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
Copy link

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

@GoEddie
Copy link

GoEddie commented Apr 23, 2015

Hey Mads - what about:

#102

Any idea where it fits?

@Eirenarch
Copy link

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

@mcintyre321
Copy link

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.

@HaloFour
Copy link

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
Copy link
Member

gafter commented Jan 2, 2017

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

@yaakov-h
Copy link
Member

yaakov-h commented Jan 2, 2017

@gafter Started on a C# 8 list yet?

@gafter
Copy link
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
Copy link

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
Copy link
Member

gafter commented Jan 5, 2017

We don't yet have plans for future releases.

@ygc369
Copy link

ygc369 commented Feb 6, 2017

@gafter
Have roadmap for C#8.0 now?

@jnm2
Copy link
Contributor

jnm2 commented Feb 6, 2017

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

@paulomorgado
Copy link

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

@ygc369
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

@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
Copy link

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
Copy link

@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
Copy link

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
Copy link

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: https://github.com/dotnet/coreclr/issues/555
  2. Class or fixed array safely embedded in other class: Please allow class contain memory of other class or fixed size array #2097
  3. Optimization for weak reference: Please make weak reference a language feature instead of class #2171
  4. Stack allocation: https://github.com/dotnet/coreclr/issues/1784
  5. Other small optimizations of GC:
    https://github.com/dotnet/coreclr/issues/1856
    and
    https://github.com/dotnet/coreclr/issues/1855

I hope more people are interested in above ideas.

@FrankHB
Copy link

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
Copy link

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
Copy link

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
Copy link

ygc369 commented Feb 8, 2017

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

@dsaf
Copy link

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
Copy link

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
Copy link

FrankHB commented Feb 8, 2017

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

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

@gafter
Copy link
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 as completed Feb 23, 2017
@lemadane
Copy link

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
Copy link
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
Copy link
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
Projects
None yet
Development

No branches or pull requests