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

  Some interest

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

  Non-language

• Generators (Proposals: dotnet/roslyn#5292, dotnet/roslyn#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 dotnet/roslyn#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 https://github.com/dotnet/roslyn/issues/2136#issuecomment-95434384:

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:

https://github.com/dotnet/roslyn/issues/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.

[GoEddie]

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

[jcdickinson]

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]

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]

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 https://github.com/dotnet/roslyn/issues/2136#issuecomment-95560417.

[ufcpp]

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

[bencyoung]

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]

IExactSizedEnumerable = IReadOnlyCollection.

[BrandesEric]

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

https://github.com/dotnet/roslyn/issues/2136#issuecomment-95570818

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.

[jcdickinson]

And building INPC into the compiler locks everyone into a specific implementation. I have personally written 3 different implementations of INPC, that approached INPC differently and needed to approach INPC differently. Metaprogramming is the correct way to completely solve the problem, especially in combination with compile-time attributes.

[bencyoung]

IExactSizedEnumerable = IReadOnlyCollection is true, so perhaps my request should be changed to Select on an ICollection should return an IReadonlyCollection rather than IEnumerable. There are other cases where an approximate or maximum size is known where other interfaces may be useful

[Mechazawa]

I strongly support adding binary literals. It would make a lot of my code less awkward looking when I'm doing things like Boolean algebra or using flags. I'm not that familiar with how the compiler handles things like base 16 literals but I don't expect that it would be much different from how they are implemented.

edit: A quick look at the source code of the Lexer reveals that it would be quite trivial to implement (somewhere around here?). Again I'm not that familiar with the compiler. I could attempt creating a proof of concept when it comes to implementing this.

[wesnerm]

Mads, there is one mistake. Static interface methods are already supported in the CLR; they are not CLS-compliant though, but potentially could be by changing the spec.

I recall that there was a .NET language that actually included this feature. I believe it is C++/CLI.

http://stackoverflow.com/questions/19496397/implementing-interface-with-static-methods-in-c-sharp

[wesnerm]

Proper tail calls is very easy to add and potentially enables a new programming style. The CLR already has support for this and languages like F# uses it. It makes an extremely elegant and natural implementation of backtracking possible, for example, without a stack! A backtracking algorithm needs a success continuation and a failure continuation.

[HaloFour]

@wesnerm Well neither is uint but that hasn't stopped anybody. :smile:

Indeed, I tested static members in interfaces in CIL and they work fine and PEVerify is happy about it. I remember them being mentioned in the Inside Microsoft .NET IL Assembler book published back in 2002.

[keilw]

@MovGP0 Good point, at least F# already support units and we're working on something similar for the Java platform, too ;-)

[rsmckinney]

Type providers :+1:

[Ultrahead]

@MadsTorgersen: "Additional generic constraints" should also refer to dotnet/roslyn#262 (which as stated above by @HaloFour already is supported by the CLR)

[garora]

What about variable declaration ?

[mhomde]

Hi guys, nice list! Nothing on pre, post and test blocks? All the features listed are really nice additions to the language, but I feel like one area that really could need some language integration is error checking and testing (nullability tracking is a great step in this direction as well) .

I think that's something that could have a real impact on the quality real-world projects which often have problems managing quality and finding bugs

Se suggestions in https://github.com/dotnet/roslyn/issues/106

[svick]

@bencyoung There is nothing that needs to change in C# for that. And the change in the framework is already being worked on, see dotnet/corefx#1282.

[dotnetchris]

PLEASE PLEASE everything in the small but useful list!

[wesnerm]

Since static interface methods are already supported by the CLR, default interface methods can be easily added to the C# language with retroactive support for older runtimes.

A class can map an interface method directly to a static interface method (with an explicit this parameter) or to a stub instance method that calls that static interface method directly. One design issue is whether default methods are public or private (only called explicitly through the interface).

[HaloFour]

@wesnerm I don't think that's the case. Adding a new "default method" would still leave a blank spot in the vtable slot that older runtimes would not know to wire up to that static instance method. You could have newly compiled classes do that automagickally but not already compiled assemblies.

[Aaronontheweb]

Default implementations on interfaces (#73) would be massively useful - Scala traits provide a great working model for this. Hope to see this in the CLR.

[horsdal]

Good to see pattern matching (and friends) so high on the list. The would/will really be an enabling feature for a lot of nice stuff.