C# 7 Work List of Features

[MadsTorgersen]

(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: Proposal: Nested local functions and type declarations #259) [currently in future branch]
• Tuples (Proposal: Proposal: Language support for Tuples #347)
• Pattern matching, part I (type patterns in switch statements and is-expressions) (subset of Proposal: Proposal: Pattern matching and record types #206 Pattern Matching)
• Ref locals and ref returns (Proposal: Proposal: Ref Returns and Locals #118)
• replace/original (part of generators) (Proposals: [Proposal] add supersede modifier to enable more tool generated code scenarios. #5292, [Proposal] enable code generating extensions to the compiler #5561)

Some interest

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

Non-language

• Generators (Proposals: [Proposal] add supersede modifier to enable more tool generated code scenarios. #5292, [Proposal] enable code generating extensions to the compiler #5561)

---

See also Language Feature Status (compiler team)

[erik-kallen]

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

[khellang]

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

[SolalPirelli]

• Supersedes

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

[dsaf]

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]

@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]

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]

@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]

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]

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:

• Semi-colon operator
• Declaration expressions
• Anonymous iterators (could be implemented with local functions)
• File-scoped namespaces (shameless plug, 20 votes and growing!)
• Better documentation solution (XML is for computers to write, not people- I'm sick of XML doc comments)

[MgSam]

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]

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]

@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]

Your strong interest list makes me very happy.

[paavohuhtala]

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

[JoshVarty]

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]

@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]

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]

@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]

What about support for auto generated object composition

[Eirenarch]

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]

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

[GoEddie]

Hey Mads - what about:

#102

Any idea where it fits?

[Eirenarch]

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

[mcintyre321]

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]

@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]

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

[yaakov-h]

@gafter Started on a C# 8 list yet?

[gafter]

@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]

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

[gafter]

We don't yet have plans for future releases.

[ygc369]

@gafter
Have roadmap for C#8.0 now?

[jnm2]

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

[paulomorgado]

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

[ygc369]

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]

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]

@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]

@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]

@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]

@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]

@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]

@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]

@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]

@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]

@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]

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]

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

[dsaf]

@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]

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]

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

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

[gafter]

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.

[lemadane]

I would like to add the alternative keywords:

1. not for ! so:

   if (not isDone) { ... }
   

instead of:

    if(!isDone) { ... }

2. and for && so

   if(isDone and isPassed) { ... }
   

instead of:

      if(isDone && isPassed) { ... }

3. or for ||

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

    if(isDone nor isPassed) { ... }
   

instead of:

    if(!(isDone || isPassed)) { ... }

5. nand for !(a && b) operation so

   while(isDone nand isPassed) { ... }
   

instead of:

   while(!(isDone && isPassed)) { ... }

6. extend const keyword for immutable variables:

   const testRunner = new TestRunner();
   

instead of:

    var testRunner = new TestRunner();

7. make ; optional, may be used it when separating 2 statements in one line.

8. true/false for truthy and falsy:

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

[gafter]

@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]

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