What’s New in C# 7.0

What follows is a description of all the planned language features in C# 7.0. With the release of Visual Studio “15” Preview 4, most of these features are coming alive. Now is a great time to take them for a spin and tell us your thoughts!

C# 7.0 adds a number of new features and brings a focus on data consumption, code simplification and performance. Perhaps the biggest features are tuples, which make it easy to have multiple results, and pattern matching which simplifies code that is conditional on the shape of data. But there are many other features big and small. We hope that they all combine to make your code more efficient and clear, and you more happy and productive.Please use the “send feedback” button at the top of the Visual Studio window to tell us if something is not working as you expect, or if you have thoughts on improvement of the features.There are still a number of things not fully working in Preview 4. In the following I have described the features as they are intended to work when we release the final version, and called out in notes whenever things don’t yet work as planned. I should also call out that plans change – not least as the result of the feedback we get from you! Some of these features may change or disappear by the time the final release comes out.If you are curious about the design process that led to this feature set, you can find a lot of design notes and other discussion at the Roslyn GitHub site.

Have fun with C# 7.0, and happy hacking!

Out variables

Currently in C#, using out parameters isn’t as fluid as we’d like. Before you can call a method with out parameters you first have to declare variables to pass to it. Since you typically aren’t initializing these variables (they are going to be overwritten by the method after all), you also cannot use var to declare them, but need to specify the full type:

Note that the variables are in scope in the enclosing block, so the subsequent line can use them. Most kinds of statements do not establish their own scope, so out variables declared in them are usually introduced into the enclosing scope.

Note: In Preview 4, the scope rules are more restrictive: Out variables are scoped to the statement they are declared in. Thus, the above example will not work until a later release.

Since the out variables are declared directly as arguments to out parameters, the compiler can usually tell what their type should be (unless there are conflicting overloads), so it is fine to use var instead of a type to declare them:

p.GetCoordinates(out var x, out var y);

A common use of out parameters is the Try... pattern, where a boolean return value indicates success, and out parameters carry the results obtained:

As you can see, the pattern variables – the variables introduced by a pattern – are similar to the out variables described earlier, in that they can be declared in the middle of an expression, and can be used within the nearest surrounding scope. Also like out variables, pattern variables are mutable.

Note: And just like out variables, stricter scope rules apply in Preview 4.

There are several things to note about this newly extended switch statement:

The order of case clauses now matters: Just like catch clauses, the case clauses are no longer necessarily disjoint, and the first one that matches gets picked. It’s therefore important that the square case comes before the rectangle case above. Also, just like with catch clauses, the compiler will help you by flagging obvious cases that can never be reached. Before this you couldn’t ever tell the order of evaluation, so this is not a breaking change of behavior.

The default clause is always evaluated last: Even though the null case above comes last, it will be checked before the default clause is picked. This is for compatibility with existing switch semantics. However, good practice would usually have you put the default clause at the end.

The null clause at the end is not unreachable: This is because type patterns follow the example of the current is expression and do not match null. This ensures that null values aren’t accidentally snapped up by whichever type pattern happens to come first; you have to be more explicit about how to handle them (or leave them for the default clause).

Pattern variables introduced by a case ...: label are in scope only in the corresponding switch section.

Tuples

It is common to want to return more than one value from a method. The options available today are less than optimal:

Out parameters: Use is clunky (even with the improvements described above), and they don’t work with async methods.

System.Tuple<...> return types: Verbose to use and require an allocation of a tuple object.

Custom-built transport type for every method: A lot of code overhead for a type whose purpose is just to temporarily group a few values.

Anonymous types returned through a dynamic return type: High performance overhead and no static type checking.

Generally you can assign tuple types to each other regardless of the names: as long as the individual elements are assignable, tuple types convert freely to other tuple types. There are some restrictions, especially for tuple literals, that warn or error in case of common mistakes, such as accidentally swapping the names of elements.

Note: These restrictions are not yet implemented in Preview 4.

Tuples are value types, and their elements are simply public, mutable fields. They have value equality, meaning that two tuples are equal (and have the same hash code) if all their elements are pairwise equal (and have the same hash code).

This makes tuples useful for many other situations beyond multiple return values. For instance, if you need a dictionary with multiple keys, use a tuple as your key and everything works out right. If you need a list with multiple values at each position, use a tuple, and searching the list etc. will work correctly.

Note: Tuples rely on a set of underlying types, that aren’t included in Preview 4. To make the feature work, you can easily get them via NuGet:

Right-click the project in the Solution Explorer and select “Manage NuGet Packages…”

Deconstruction

Another way to consume tuples is to deconstruct them. A deconstructing declaration is a syntax for splitting a tuple (or other value) into its parts and assigning those parts individually to fresh variables:

Parameters and local variables from the enclosing scope are available inside of a local function, just as they are in lambda expressions.

As an example, methods implemented as iterators commonly need a non-iterator wrapper method for eagerly checking the arguments at the time of the call. (The iterator itself doesn’t start running until MoveNext is called). Local functions are perfect for this scenario:

If Iterator had been a private method next to Filter, it would have been available for other members to accidentally use directly (without argument checking). Also, it would have needed to take all the same arguments as Filter instead of having them just be in scope.

Note: In Preview 4, local functions must be declared before they are called. This restriction will be loosened, so that they can be called as soon as local variables they read from are definitely assigned.

Literal improvements

C# 7.0 allows _ to occur as a digit separator inside number literals:

var d = 123_456;
var x = 0xAB_CD_EF;

You can put them wherever you want between digits, to improve readability. They have no effect on the value.

Also, C# 7.0 introduces binary literals, so that you can specify bit patterns directly instead of having to know hexadecimal notation by heart.

var b = 0b1010_1011_1100_1101_1110_1111;

Ref returns and locals

Just like you can pass things by reference (with the ref modifier) in C#, you can now return them by reference, and also store them by reference in local variables.

This is useful for passing around placeholders into big data structures. For instance, a game might hold its data in a big preallocated array of structs (to avoid garbage collection pauses). Methods can now return a reference directly to such a struct, through which the caller can read and modify it.

There are some restrictions to ensure that this is safe:

You can only return refs that are “safe to return”: Ones that were passed to you, and ones that point into fields in objects.

Ref locals are initialized to a certain storage location, and cannot be mutated to point to another.

Generalized async return types

Up until now, async methods in C# must either return void, Task or Task<T>. C# 7.0 allows other types to be defined in such a way that they can be returned from an async method.

For instance we plan to have a ValueTask<T> struct type. It is built to prevent the allocation of a Task<T> object in cases where the result of the async operation is already available at the time of awaiting. For many async scenarios where buffering is involved for example, this can drastically reduce the number of allocations and lead to significant performance gains.

There are many other ways that you can imagine custom “task-like” types being useful. It won’t be straightforward to create them correctly, so we don’t expect most people to roll their own, but it is likely that they will start to show up in frameworks and APIs, and callers can then just return and await them the way they do Tasks today.

Note: Generalized async return types are not yet available in Preview 4.

More expression bodied members

Expression bodied methods, properties etc. are a big hit in C# 6.0, but we didn’t allow them in all kinds of members. C# 7.0 adds accessors, constructors and finalizers to the list of things that can have expression bodies:

Join the conversation

Would also love to see this, but don’t hold your breath. They’ve made it significantly difficult to use in the current state with the CodeContracts package/tools. No idea why they aren’t making that with a better syntax part of the language.

Nothing on design by contract this time around, and I’m not sure if there will be anytime soon. We’ve looked a lot at contract-style features, and they tend to get quite verbose and complicated. I am not sure that they would carry their weight in added value as language features. But maybe, one day, if we can get the design right.

While people do use CodeContracts for many things, the 90% case seems to be dealing with null. We are eager to tackle the language integration of that in a more type-system-oriented way, allowing you to distinguish between nullable and nonnullable reference types and track correct usage based on that. I hope this can happen in the next major release of C#.

More than anything else, you could make me happiest if the next version of C# has support for non-nullable references. I’ve been waiting for that for years… if I remember correctly, it was in a research language, perhaps Cω at one point. I followed Github and at one point it was being talked about for this version, but it seems to have been pushed back. I’d be absolutely fine if this is the one and only feature that makes it into the language. That said, I’m not sure that C# language support is enough to make this a successful feature. It may require changes to the CLR runtime as well. But it would be worth it. As we all know, NRE are the single most costly bug in all software development. While I may not follow the Github discussion as much anymore, please count my vote for non-nullable reference types.

2 years ago

Jiri

I vote for non-nullables too ! 🙂

2 years ago

Marek

Exactly! I used non-nullable types in Spec# when I was working on Microsoft Singularity project and I miss them a lot. Definitely something I would love to see in C# in the future as this would greatly help with avoiding NREs without sprinkling your code with if statements everywhere.

2 years ago

MuiBienCarlota

Non-nullable references were mentioned for .Net 1.2. They disappeared after the postponement of this version and its rebirth as a .Net 2.0 more than one year later.

They was also implemented in spec#, a research only sharp language.

All these efforts show that it is important. I’ve always be fan of & and const & in c++ and I was sorry to lose it in C#…

2 years ago

Farzad E.

I don’t think you’re alone in this Craig.
I remember voting for this feature almost 5 years ago and back in 2012 it was one of the top most requested features on UserVoice and it was one of the most awesome features of Spec#.

Frankly, I was at a loss for words when one of my colleagues told me that all this would be useless in Core. Imagine the work we now have to do translating all of our hundreds of interface contract checks.

Please please please keep asking for things related to VB.NET. As the program manager for Visual Basic it’s absolutely critical that I get feedback from my customers–Visual Basic developers–on the scenarios and technical challenges that matter to them most. It’s my favorite language and I want to keep it a language for success for the customers that love it as much as I do. If there’s a feature or capability you feel you can’t live without, drop us a line on https://github.com/dotnet/roslyn or send me a tweet @ThatVBGuy!

Though not essential, genuine out parameters (i.e. an Out modifier to complement ByVal and ByRef) would be great in VB. The reason is that components with methods that use Out parameters use ByRef parameters in VB instead, which means you are forced to initialize variables passed to these parameters to values that will never be used to avoid the “Variable _ has not been assigned a value, a NullReferenceException could result at runtime” warning. Yes, you can turn that warning off. Yes, you can ignore that warning. But that is like the fire alarm that always has no batteries or that goes off each time you turn on the stove. A genuine out parameter offers no new capabilities, but it does give a nice clean way of saying “yes, the variable is uninitialized, and no, this will never matter in this case.” But more importantly, it makes VB-built components better to use from C#, because C# users will not have useless ref parameters that must be needlessly initialized, just because in VB you must use ByRef or ByVal.

I realize that this would be a large feature to implement, but it would be a big winner I think, and in keeping with the unique capabilities of VB.NET. While I have (for many reasons) never liked the REST paradigm which made JSON so popular as a replacement for SOAP in Web Services, JSON in and of itself is another story. It offers advantages over XML, like a true array construct, and the open/close brace is shorter than the open/close tag, and Visual Studio is embracing JSON more and more, like it did XML since the beginning. So, how about 1) a native Linq-to-JSON framework, i.e. JElement, analogous to XElement, similar to what NewtonSoft (www.newtonsoft.com/json) offers, but as a native part of .NET, and 2) JSON literals in VB code, like the XML literals supported for several versions (which I use all the time, in nearly every project), and corresponding VB extension methods for reading JSON object properties, querying for descendant objects, etc., similar to Linq-to-XML?

Completely agree. VB.NET must die, because it is a complete waste of human resources. After that it would be good to focus on slowly killing JavaScript by replacing it with C# running in limited functionality mode. Web browers could check C# code to make sure that all methods are allowed and compile it on the client side. I really would like for cross-platform browers to use Mono and start supporting this tag on cliend side:

…

Imagine posibilities. It would be so easy to extend it by just unlocking current libraries of C# on the client side. For example various math libraries which are safe to use from security point of view.

“Yes, when you also have the Keys of Barad-dûr itself, I suppose; and the crowns of seven kings, and the rods of the Five Wizards, and have purchased yourself a pair of boots many sizes larger than those that you wear now. A modest plan.”

2 years ago

Christopher Bordeman

The next HTML spec is supposed to include a bytecode substitute for Javascript, allowing any language to be used. So no «script type=”text/csharp”» but a “binary/bytecode” option where you compile C# on the server. So in the next 5 years C# in the browser could be a reality.

@Christopher Bordeman there’s already a fair level of support for running C# in the browser today with projects like JSIL, Bridge.NET, and several others I never knew of when i was googling for these names.

While compiling C# for client side consumption would make sense from a .NET point a view (and laziness), have you looked at TypeScript? If you are wanting something that allows you to do exactly what you are talking about this is what you can do today and based on the trajectory of TypeScript it will only get better in the future. This would allow you to have the OOP style programming with the check and it does the hard work for you of generating the JavaScript that can be used in all browsers today.

There are already several C# to Javascript transpilation projects, the most noteworthy of which is http://www.bridge.net
It has some kinks, but I’ve already used to to write several small applications without any major problems.

Completely agree with you on both points, especially on JavaScript which is spreading like a cancer in a form of numerous frameworks being released almost daily now forcing developers to give up on all the best practices of OOP, strong typing and software design we worked so hard on over the last few decades…

Better yet, one of you c-sharts could conquer your insecurities and accept that there is more than one development language in the world. Just imagine what you could do with your day if you weren’t constantly fretting about what languages other people were writing in and demanding that reality be warped to your unilanguage mindset! You might even be able to learn a second, or even a third language, just like the grown-up programmers do! Then you could go proselytize to the rest of the c-shart community and make the world a better place!

haha !! VB die !? why …
just make a xml document in both c# and vb and feel the power 🙂
or vb support property with parameters and c# don’t ..
vb is easy to read
and and and …
maybe they should let c# to die.

working in both VB and C# on a daily basis i can say they are pretty much the same, although the VB lambda syntax is a little verbose. I like the C# syntax more but when working with both you will see they are pretty much similar.

You should seriously consider switching to C#. It’s really not that hard to learn and once you do, you’ll wonder why you didn’t switch earlier. It will also give you more weight when looking for jobs. Very few employers are looking for VB.Net developers. I used to be VB 3 and VB 6, then VB.Net, and decided to give C# a try and it was so similar to JavaScript in it’s syntax, that it was really easy to get up and running.

I programmed in VB (classic) for 16 years. I started in .NET using VB.NET for the first few years but find C# to be superior for its terse syntax. I hate semi-colons but find that overall since the feature sets are nearly identical I would rather read and write less code. The learning curve was simple since there are numerous sites that tell you the C# keyword/syntax for its VB.NET equivalent. I also find many more samples and open source projects in C#. I loved VB (classic) and had the syntax remained closer to its roots VB.NET may have been a good upgrade. Instead it was a completely new animal.

If I can read between the lines I think you’re asking “What’s New in VB 15?”. Good question. We’ve been working on VB 15 at the same time but didn’t get it in in time for Preview 4 (which is the topic of this post). Tuples, a story for consuming ByRef returning methods and properties, pattern matching/type-case/select-case-on-type are all in the works. And we’re working with an open source VB developer who’s trying to contribute a feature. We’ve never added everything we do for C# to VB or VB to C#. That’s not how language design works. So, for example VB.NET has a much stronger starting position with lambda expressions than C# (VB already supported iterator lambdas) did so local functions would have more overlap. The actual back-compat concerns with pattern matching and the design in the two languages is different because of differences in Select Case and switch. The way the languages handle ByRef arguments is different so there are consequences there. There were features in VB14 that weren’t in C# 6 and features in C# 6 that weren’t in VB14. It would be a mistake to attempt to measure the capabilities or future of either language based on whether they always copy each other letter for letter.

But the point is taken, you’d like a post on the topic. I’ll get on that.

Thanks! It would be great to make a post explaining to people that VB.NET is not VB6. I personally prefer VB.NET over C# because it’s equally powerful and much easier to read and write. I don’t understand why VB.NET gets so much hate, except perhaps that everyone associates it with VB6. Let’s rename VB.NET to C#+.NET! 🙂

VB is a fine language in isolation, and it’s select case implementation alone almost makes it a superior development language on the Windows platform ;). It’s just that almost all the other currently big languages out there (C++, JavaScript and Java) use the C syntax, and that is why C# is vastly more popular.

1 year ago

Chidex Josh

Seriously I don’t know why some developers hate Vb. Net.
Pls Vb team should make this clear to the general public on the fact these two languages Vb. Net and c# are equally the same… Just syntactically different nothing more.
And Vb. Net is also as powerful as any other language can be.
I love Vb. Net

F null. Seriously, the language should be doing away with nulls everywhere it can. It has in many places, but some places they can’t really… since they started with String being nullable that will never change, but I wish it would. Nulls are the antichrist.

An object should represent something that is tangible and within the grasp of senses. Supporting null is like building a closet that you can never ever put anything in. I have no need for such a closet.

One day you and the question mark will be friends Ben and Mathieu. You don’t know it yet, but you will reach that point.

And then they will introduce tri-states 😀 Variable has value, Variable is null , Variable is awaiting Value :)’

1 year ago

Ioannidist

@Mathieu

An object, always represents something tangible. ‘Null’ is assigned to variables, not objects. A variable may or may not hold (point to, refer to) an object.

Supporting null is like building a closet that you may or may not put (according to the circumstances and needs) something in it.

Suppose you have an object hierarchy where one object mayor may not “have” a reference to another object (and that’s perfectly normal). For instance a “Person” object may have, or may have not an “address” field which corresponds to an “Address” object with many fields (street, number, city, postal code etc).

How would you represent a “Person” without an address if you don’t nullify the “address” field?
Would you create a “dummy” address object in order to represent an absent address for that “Person”? In that case you go against your own words “An object should represent something that is tangible and within the grasp of senses”. Because you would have an “Address” object that would not represent something that is tangible and within the grasp of senses. It is an object that represents it’s own absence.

The problem with _ is that _ is a perfectly fine name for a variable. Perhaps not a best practice, but certainly legal. Also, regarding null, “int @null = 5;” too is valid. “(var x, var @null) = GetFoo();” should be legal. Perhaps without the @, null alone could be made to mean “don’t care”, but the design is questionable in my opinion. int * = 5; is not valid, nor is int @* = 5;, so * seems to be a fine choice.

Interesting idea. The two main options that were discussed so far were * (star) and _ (underscore).
Personally, I like _ (underscore). I think null would be a bit confusing, as it suggests passing a value.
There are a few contexts where wildcards could be used and that need to be considered: out vars, deconstruction declarations, pattern matching.

Just want to add that _ already is a valid identifier in C#, so trying to make it also a wildcard in a compatible way would be difficult.

Personally I want to say that it didn’t take me long to warm up to * in this capacity. 🙂

2 years ago

Andres G. Aragoneses

Given that * is chosen because _ can’t be chosen, it reinforces the idea that it’s a bad decision, ultimately a hack. Especially considering it clashes with unsafe C# pointer syntax…

Why don’t you deprecate _ as a valid identifier in C#7 (raising a warning if used), and introduce wildcard identifiers with _ in C#8? You could even make the compiler not accept them if there is any variable named _. So just let _ wildcard identifiers be used by people that have already opted out of using _ as an identifier.

Ditto. “void” definitely looks to me to be the best option here. My 2nd choice would be “null”. But “*” does not fit with the style of C#. Also, it doesn´’t make any sense to call it “wildcard” since for me, wildcard means “any value/variable”, while in this context it means “no value/variable”.

I agree with using ‘void’. It fits with the existing usage of this keyword : no output.

The ‘*’ token is already used for multiplication. Granted that it wouldn’t be the first case of the same keyword being used with different meaning (I’m looking at you, ‘using’), but why do it if another keyword fits near-perfectly?

Besides, if it’s to lessen verbosity, I’d say minus ‘-‘ would probably be better than ‘*’ to avoid confusing its intent with that of a greedy wildcard from patterns and regexps.

To ignore an out variable, you plan to allow “wildcards” like
p.GetCoordinates(out int x, out *); // I only care about x
but including the Keyword out.

As for out variables, you plan to allow “wildcards” in deconstruction like
(first, *, last) = LookupName(id2); // I only care about first and last
but excluding the Keyword out.

It seems to be a little bit confusing…

What does the wildcard mean? I don’t care about the (always?) back coming value.
I want the value to be destroyed.
So, what about using the tilde as in destructors?

(first, ~, last) = LookupName(id2); // I only care about first and last
Readable as “Take first, destroy middle, take last”.
or
p.GetCoordinates(out int x, ~); // I only care about x
readable as “Take x, destroy whatever comes next”

‘null’ looks really confusing. ‘int’ is not a reference type, so ‘int(null)’ or ‘out (int)null’ looks really wrong. Even simply ‘null’ looks wrong in this case (and is potentially ambiguous). Passing ‘null’ where the method is expecting an ‘int’ just looks very wrong.
Also, ‘null’ is a VALUE and we’re passing in a VARIABLE. It has a different meaning.

For the same reason, ‘void’ looks weird, too. It’s a type, not a variable.

I never understood the appeal of _
It is only considered because some other languages use it.
Besides, it already is a valid identifier, so it would be problematic.

* clearly looks like a wild card to me.
It has to “look off”, because it is special. Wild cards are new to the language; it needs a new symbol.
I don’t see a problem with *

It probably isn’t null. I imagine that the current * design would create invisible locals that are passed just regularly but not used anywhere. If you would be passing null, that null would appear on the inside of the method with that out parameter. And having null as an out parameter is pretty ugly… You can’t test it and you can’t write to it. out parameters are probably comparable with references in C++, not to be confused with pointers. Pointers can be null, references not. null is definitely wrong, if my assumption of the implementation is correct. After all, this is just a language feature, the CLR must remain unaware of it.

Anyway, I share the dislike for that * character in the code. An ellipsis (…) is probably not much prettier, too. (BTW, you can write three dots or one … ellipsis character.)

I appreciate the efforts to make these features feel cohesive with each other and with the existing language. Tuple types that are anonymous but can have named members are a great feature.

I’m kind of wary of features that encourage side effects in expressions, or using expression syntax in places that are inherently about effects (e.g., constructors.) For clarity I strongly prefer to keep imperative code in imperative style, and save the expression/functional style for code that is really about values. Of course there’s no way in C# to really enforce or be pure about this.

Yeah, I get what you’re saying. C# is rooted proudly in a C tradition, with side effects and results all muddled together in the same constructs (such as function invocation).

In C# 6.0 we avoided expression-bodied members when things couldn’t possibly have a result (such as e.g. constructors and finalizers), but on the other hand we allowed it for methods even when they didn’t. So that was a bit inconsistent. Some of the new expression bodied members are mostly just filling out that gap, and returning to more linguistic consistency. And if you care less about the purity of it, they are a great opportunity for abbreviating some simple members.

That said, I think that e.g. the expression-bodied get accessors are neat and useful.

Exactly for this reason I made ReSharper do not suggest to use expression bodies in the case of single assignment inside statement-bodied members and lambda expressions. Side-effects should not be hidden inside expressions if possible. We all know this since `if (x = 42)` disaster in C – assignment expression should really be a statement (and statements have no value).

And now I’m working on more IDE features to enforce explicit side-effects to be made in statement forms where possible, while you’re making the class members declarations that inherently contains side-effects (constructors, set accessors) expression-bodied 🙂

While I understand the idea to unify the type member syntax, I don’t understand the idea of introduce even more syntactic freedom in a language 🙂 Especially property declaration (already overly complex), now it may look like:

Still trying to understand why pattern matching has been introduced to the switch statement..none of the OO developers will use that anyway, maybe in the next few years we might get what scala offers to the community. I like C# but the way its pushing further comparing to some of the other popular languages and in this modern area where more and more we as developers are involved in building distributed applications, pattern matching, records etc would be much more appreciated and will speed up the dev process and the productivity. maybe this sounds rude but in fact that’s the reality which we are facing everyday.

Well, we do hope to add a `match expression` to C# in the future, which will be an expression-based, much leaner syntax for switching with patterns.

But when adding a whole new concept to the language, such as patterns, we think that it’s vital that it fit in well with the existing language constructs. Hence the initial focus on `is` expressions and `switch` statements. We don’t want to glom on some separate functional language to the side of C#. we can (and do) borrow eagerly from functional languages such as F#, but we have to do it in a way that is really deeply integrated into the feel of C#.

This, by the way, is very similar to, and in no small way inspired by, the philosophy of Scala, which holds that functional and object-oriented programming aren’t like oil and water, but can in fact be blended pretty well. Scala did it from the start, whereas we began in a mostly object-oriented place, and have been trending functional ever since. But hopefully programs aren’t necessarily written in the “object-oriented” or “functional” subset of C#, but instead just good code taking advantage of the full range of expressiveness.

Now that we’ve found an approach to patterns that does fit super well into existing C#, we can think about where to take it next in terms of a) which other patterns are interesting, and b) which other constructs can we put them in.

Do you plan exhaustive type checking (like with f# discriminated unions, and the new switch in TypeScript)? This feature really helps with extending return values types while getting compiler-level confidence that you’ve covered any new return values.

Also, am I right in thinking that .Item1 etc. will be the names that reflection returns? If so, will there be any way of finding the descriptive names via reflection, or from outside an assembly if they are used on public return types?

exhaustiveness: It’s on our radar. There needs to be a way to declare types that have a fixed number of possible values. Some languages do this with discriminated unions, but adding a new kind of type declaration to the language should not be done lightly. If we do – or find some other way of expressing exhaustiveness – then we will certainly take advantage of it by having the compiler warn whenever a match is incomplete.

Reflection: The user defined names in tuples exist only at compile time. They are exposed in metadata as attributes on the parameters, return values etc. that have tuple type, not inside of the type itself. This turns out to be by far the best representation, both when it comes to efficiency and allowing the flexible equivalence between tuples with different names that we want. But it comes at the price of not being able to check those names at runtime, through reflection, or type checks, or otherwise. They simply aren’t there.

Yes. Our general goal for language features is to make sure they work across all our .NET offerings (.NET Framework, .NET Core, Mono, Xamarin etc). However, there are language features that have dependencies on APIs provided by the underlying platform. In many cases, such as tuples, we can get away with providing the functionality out-of-band so you can use new language features on existing platforms without having to wait for all platforms to catch up provide the functionality in the core.

Having tuples return type may make the code look more complex but it can help reduce the amount of effort in making out variables which was equally hectic, What is the performance measure using the tuples in the code rather can having multiple out variables ?

Good question. The performance characteristic is probably quite specific to the size of the argument and the number of operands. Out parameters essentially require an indirection to write to specific address, so all out variables end up being pointer sized. Tuples are value types that are returned by copying.

In case of out variables, wild cards shouldn’t have any performance benefits. In IL you’re forced to provide a slot that the calling method can write to. So if you specify a wildcard, the compiler will simply emit an unnamed local.

No, this syntax is not supported. In general, there’s no reason to expect different tuple elements to have the same type, so we aren’t planning this abbreviation. Note that the `var (…)` syntax can infer different types for each variable. So these three lines all mean the same:

LOL. I think it’s more that 0-based arrays it a consequent of pointer-arithmetic. 0 is an offset into a data structure whereas tuple elements have ordinals. The 3rd element of an array is at <beginning of array in memory) + ((3 – 1) * sizeof(arrayelement)). It's convenient that for the first element that's 0 and it cancels out all the terms (yadda yadda math geek). There's nothing comparable in the tuple space because each element can be of a different size. All you can say is that it's the first or second or third element. That tells you nothing about where it is in memory, really.

That is a fair point, but our hands are tied by historical decisions. System.Tuple types were introduced in .Net framework 4, which you can use in any .Net language and are used ref tuples in F#, and their first element is called Item1.
C# tuples are a convenience syntax on System.ValueTuple. It is a strong requirement to keep ValueTuple and Tuple be consistent and as close as possible, so they also must have Item1 as their first element.

All proposed features seem like they’d be great additions! I’d also like to see wildcards. I tend to use _ now, but I could see using * instead.
I’m especially interested in the generalized async return type feature. Will this mean that IAsyncEnumerable and IObservable could potentially be used as async return types?

_ is just a convention for variables you don’t care about, it is not enforced in the language. If another developer is not aware of the convention (or just purely evil) he/she can start using the variable, confusing everyone who is aware of the convention. This developer might not be aware of the meaning of * either, but the compiler makes sure it’s not misused.

Generalized async return: yes, in principle IAsyncEnumerable and IObservable could be augmented to be allowed as async return types. We would have to provide builders for them. The only thing those builders could currently do is return single-value implementations, since there is not (yet!) a notion of async iterators.

That’s something we’d like to look at further for the next version. I think it’s better to wait for async iterators before we consider builders for these interfaces. However, if you want, you can make classes that implement those interfaces, and you can make your own builders for those. It’s not going to be easy getting it right! Stay tuned for more details and a working implementation of the generalized async return types.

How do the new tuple types work in a dictionary? Will the types gain an IEquatable implementation? Or will EqualityComparer.Default detect a type which inherits from TupleValueType and do something special to use all the fields?

If so, I hope it does this without resorting to reflection, which arguably ruins the performance of otherwise handy Enum operations like TEnum.HasFlag().

System.ValueTuple types and by extension C#/VB tuples do implement IEquatable, as well as a number of other equality interfaces (IComparable, IStructuralEquatable, IStructuralComparable), just like System.Tuple did.

The `operator is` was an earlier proposed syntax for what eventually became the `Deconstruct` method. They serve the same purpose, which is to describe how an object is deconstructed, and both have potential to grow more expressive as C# evolves (to allow something like F#’s “active patterns”, for example).

Deconstruction does not yet work in patterns. We hope to get to that soon, but not in C# 7.0. In general, think of patterns as a new concept that has taken root in the language and can evolve over time.

I’m still hoping this will evaluatie to an nullable int some day:
var age = isPerson ? 1 : null;
now you have to choose between a few options that just don’t feel right:
var age = isPerson ? (int?)1 : null;
var age = isPerson ? 1 : default(int?);
var age = isPerson? (int?)1 : (int?)null;

And I know session should just be disposable. But it just isn’t always. And there are use cases you want to use variables in you finally and catch, that are declared in you try block. Now you need to:
{
var session
try
{
session = OpenSession():
// do stuff
}
finally
{
session?.Destroy();
}
}

If you write a mutable struct in the usual encapsulated way, with private state and public, mutator properties and methods, then you are in for some bad surprises. The reason is that whenever those structs are held in a readonly variable, the mutators will silently work on a copy of the struct!

Tuples, however, simply have public, mutable fields. By design there are no mutators, and hence no risk of the above phenomenon.

Also, again because they are structs, they are copied whenever they are passed around. They aren’t directly shared between threads, and don’t suffer the risks of “shared mutable state” either. This is in contrast to the System.Tuple family of types, which are classes and therefore need to be immutable to be thread safe.

Timing-wise, that doesn’t seem likely. The hold-up is primarily making sure that we build a source generator API that is a pit of success from an efficiency standpoint. This needs some bake time.

At the language level, things aren’t all that complicated. We’ll add the original/replace features when source generators are getting ready to ship. We’re open to doing it in a point release of the language, if necessary. But we don’t want to release them too early, either, since they are being codesigned with the broader source generator feature – we want to make sure that we ship the right thing for the scenario! 🙂

The syntax for local functions is less than ideal. When I see an unconditional return in a method, I expect anything below it to be unreachable. But with the introduction of local functions, this preconception now vanishes. I suppose one could argue that the local function is not really reachable–and in some strict sense that is true–but it certainly makes the code more difficult to read in my opinion. Can the local function also be declared at the start of a method? Not that that would make the code any easier to read, but at least it does not directly after the method return statement.

There seem to be different preferences around where local functions should be declared. Some would like to declare them first, like you outline, and some at the end, after the enclosing method’s return statement, where they are not “in the way” of reading the main flow.

We will allow both. The current prototype only allows them to be declared before they are used, but we are fixing that.

There’s some pretty nifty definite assignment analysis going on with local functions, by the way. Getting this right was one of the reasons for the current restrictions in the preview. This has to do with when the local function uses variables and parameters from the enclosing method:

* We track which enclosing variables the local function reads from. It is an error to call it before those variables are definitely assigned. That way you can’t use local functions to accidentally see uninitialized state.
* We track which enclosing variables the local function writes to. This lets us know that when you’ve called it, those variables are assigned. That way you can use local functions to initialize your variables, for instance.

async does other things than allow awaits. You can write an async method without awaits (though you get a warning).

More importantly, it is a lot easier to see if a method is async when you have to declare it rather than search for the use of a given keyword somewhere in the body. If we could do it over, we would probably have done iterators the same way – with a modifier on the method, rather than depending on “yield” showing up somewhere in the body.

My thoughts are a bit different. It looks like that C# is becoming polluted with all kinds of tricks. I’m afraid that this could lead to a big ball of mud. It isn’t really necessary for each new iteration of VS to have new language features, or that many of them.

Don’t get me wrong. Most of this stuff is great and I use a lot of C# 6 features as well and am going to use these too, but the pollution scares me. The language will have better features in the future, but the “obsolete” ones will remain and pollute. Then what? Too many unecessary features that are obsolete and no one uses them, but cannot be removed due to historical reasons. The learning curve for a beginner to the language could rise dramatically.

I’m just asking have you guys thought of that? Also do you have a longterm plan for the language, i.e. what do you want in C#10 and where do you want the language to go? Or is your goal to switch C# from OO to functional language or a mix of both or a new bread :)?

You hit on something very central to language evolution. We can add, but we can never take away. This weighs heavily on our minds as we evolve C#. Anders famously says that “every feature starts with minus a hundred points”. For every feature we try to think about whether people will appreciate it not only now, but ten years from now. We try to think about whether it’s worth not only the work involved today, but the space it will forever occupy in the language surface area.

We’re often right, but not always. As you know, the future is one of the hardest things to predict. 😉 And this brings us to another aspect of our design approach: we need to be bold. We need to not be stymied by our responsibility to a distant future. Because otherwise we won’t have that future. C# needs to be among the greatest programming languages today, or it won’t be among them tomorrow.

So we do add things pretty aggressively. We try to add the most valuable features to developers. Moreover we try to add them in a way the minimizes the “agin” of the language in terms of added complexity. Yes, pattern matching is a new feature, but it works in existing constructs such as “is” and “switch”, and over the existing kinds of types. It is (hopefully) well-integrated with our past. At the same time, it introduces patterns in a way that leaves lots of room for them to grow as a concept, without that generality introducing a tax today. It is well-integrated with our plausible future.

You won’t believe how much time we’ve spent speculatively designing the possible futures of patterns, just so that we could make sure to remain open to them. This is part of how we try to keep the language’s long term health and viability at heart as we add new features.

I hope that helps give a picture of how we think about the long term evolution of C#?

Have you considered taking away? This would obviously brake old code but I think that is not as bad as it might seem. It is possible to develop tools which would migrate old code to new code and those tools could be integrated into VS.
And even without tools, migration to new code by hand is done once and everything is fine. The amount of work isn’t that much. The amount of work that accumulates from less readability and learning in code that contains legacy code is hardly measurable but i think it exeeds the work of migration.

Looking at the Python3 as the not backward compatbile successor to Python2 language (with “2to3” tools support) indicates otherwise. Python3 is around for many and it is still a source of confusion, irritation, and debate.

Regarding switch and patterns (as well as other enhancements)…. Unless magic is happening, it seems the switch statement is degrading into syntactic sugar over a set of “if {} else if {} else if {}” rather than the original capability of being a high speed indexed jump table.

The compiler devs on this feature are very focused on optimal code generation. There are many things you can do to optimize, such as factor out shared tests, reorder, etc. Switches with just constants will continue to be as efficient as they are now, and then as the patterns get more complex, obviously that is going to have a perf impact. But in general, we can make a switch at least as, and often more efficient than the if/else chain you would have had to write yourself to do the same tests.

Is there anything plan to have more control on the immutability of methods/arguments like the const keyword of C++?
I’ve never understand why it’s still not around, it’s great for the developer to know a method/data can’t be changed by the callee and I’m sure the generated code can benefit of optimization in such case.
Thanks

I agree. Lack of support for designing in immutability into your code/types is in my view the thing that is most obviously lacking in C#, so it’s a shame that there’s no movement on this. Having said that, I suspect it may be hard to add immutability features in to C# without also adding such support into IL, which possibly restricts the C# designers’ freedom in this regard. And there is the issue of proliferation of features making the language too bloated – which I think is already happening, even without support for immutability.

We do have features on the radar for that, but haven’t acted on it so far.

A simple solution is to allow the “readonly” keyword on all parameters and locals. One problem is that when you write in a certain style, ALL parameters and locals should really be readonly. And now you end up with this attractive nuisance of nine extra characters bloating every declaration. It’s an “attractive nuisance”: it makes the world a little better, but better enough?

A way to reduce the bloat to something acceptable would be to have an abbreviation of “readonly var” to maybe “val” or “let”. That would at least take care of locals that are initialized. Is that a good enough fix to make this worthwhile? Not sure yet.

Is there a spot in the plan for a more strict version of the `readonly` modifier on members? Currently, as I understand, `readonly` members can still be modified with reflection, making some performance optimizations by the JIT compiler impossible.

A readonly keyword put on a method would be already a great start, then the implem of the method couldn’t modify data members of the object it’s called upon not called non read-only methods. But we would still need a keyword like the C++’s mutable to be able to override this rule has it has been proven a necessary thing (e.g. when you put in a cache the result of a get operation for a faster next get).
For me immutable methods are really important in the design of your APIs, it should be also supported in the interface declaration.
Next would be readonly parameters of a method, it’s also important because it’s a great constraint to let the user know about (and I think the compiler could benefit from it to speed things up).
Last, readonly on local, well I’m not sure there’s a true value out there, it’s really an implementation hint that tends to annoy you at the end of the day because you can easily start to declare many local as read-only and a small change oblige you to remove this immutability on many things. It’s like the const in TypeScript and I really don’t use it, because I think there’s not real value.

To sum up, it’s all about contract between the API design and the user of the API, such thing lacks a lot for me.

There’s a fabulous amount of research on “this types” or “self types”. My own view is that they are somewhat useful but

* Add a bunch of complexity to the type system, while
* They still aren’t general enough to express many “covariant” patterns.

The languages that solve this best, in my opinion, are ones that have some variant of “virtual types”, or what Scala calls “abstract types”. That’s really a very expressive mechanism. But realistically I don’t see us trying to embrace that in C#; that would be a massive effort down through the runtime, for not enough benefit.

Loving some of the enhancements. I’m a little uncomfortable with deconstructors being a method, although it does allow it to be called outside of deconstruction, this is not necessarily a good thing. I’d personally prefer it being a special case, such as constructors, and finalizers. The main reason being to make refactoring easier – for example, it’s not obvious that renaming the method would break any Deconstructing assignments and/or declarations – particularly in 3rd party libraries.

Also, rather than returning void and using out parameters, why not make use of the Tuple return syntax itself, which is less verbose and clear.

You could use the class name, as methods are not currently allowed to share the name of the class (to prevent ambiguity with constructors) so if you use a ‘constructor’ with a tuple return type, this is easily disambiguated by the compiler, and produces a very clear and succinct syntax:

To further expand on my objection to the current syntax, I’ve been racking my brain for examples where classes have features introduced to support new syntax.

1. Constructors/Finalizers which is where I’ve suggested Deconstructors could/should live.

2. Operators – this is a possibility, but is more verbose e.g.
public static (int x, int y) operator Deconstruct(Point p) => (p.X, p.Y);
Though, what would explicit operators mean (or do just disallow them)?

3. Interfaces (e.g. ‘using’ support of IDisposable) – not applicable as the signatures necessarily need to change.

4. Extension methods – again possible, but I don’t like and what do you call the method? You could use ‘~’ perhaps or ‘Deconstruct’ (but the linking would then be magic as with the current preferred syntax)? e.g.
public static (int x, int y) ~(this Point p) => (p.X, p.Y);

Of course, the 4th option is the only one where you can also call the method directly, whereas 1 & 2 do not expose methods on the objects, which I believe is preferable – just as you can’t call the operators directly.

In all cases, the syntax at least tries to indicate to the developer that something special is going on…

Source generators will not be in C# 7.0. We hope to do them after, but any guess about when exactly would be speculation at this point: we are actively working on them, and we will ship them – and the associated language features – when we get them right. 🙂

With havin so much content do you ever run into any problems of plagorism or copyright
violation? My website has a lot of exclusive content I’ve
either created myself or outsourced but it seems a lot
of it is popping it up all over the web without my agreement.
Do you know any methods to help reduce content from being stolen? I’d truly appreciate it.

I see the way we design the language pivoting a little. Or an inversion of control, so to speak. It’s not that the version number decides when a feature shows up, the feature reaching readiness will decide the version number (major or minor). For a feature with the kind of potential impact that source generators could have we don’t want to rush them and fail to fully explore the design space because of a deadline. I want the community to have the right amount of bake time to use the features and help us find the sweet spot. The best way you can help us get the best features into C# and VB faster is by participating in the design discussions on GitHub, downloading the prototypes and feature branches, and just throwing your most creative uses at the features. We’ve done a lot of work in Roslyn to make sure you aren’t just limited to using features when we snap them to a preview, you can get the sources for the features as we’re developing them. Long before there’s any official “C# 7 + 1” VS beta. And it’s going to be that community participation, I believe, that drives most the language evolution rather than a particular version number or release schedule.

Thanks for paying attention on GitHub and continuing to ask us about this. Keep up the good work!

Why introduce both out variables and tuple return/deconstruction? Programmers designing functions that “return” multiple values would have to pick one over the other and IMO returning a tuple is shorter, clearer and provides more opportunity for optimization (with out parameters you have to emit load and store instructions because the reference passed in might be aliased elsewhere and accessed from another thread).

Is the introduction of out variables meant just to simplify programming against existing code that uses out parameters?
The added convenience might encourage programmers to use out parameters more often.

Yeah, that was a bit of a dilemma for us, but we ended up believing both have a place. We think that in most cases people should use tuples for multiple results. There are some cases where that is not a good idea:

* when you want multiple overloads with different sets of result values: you cannot overload a method on return type. (That is the reason why the “Deconstruct” method used by deconstruction takes out parameters instead of returning a tuple)
* when you implement the Try pattern you want to just return a single bool, so that you can write the call in e.g. an if condition. You want additional results to come through out parameters instead.

“Generally you can assign tuple types to each other regardless of the names: as long as the individual elements are assignable, tuple types convert freely to other tuple types. There are some restrictions, especially for tuple literals, that warn or error in case of common mistakes, such as accidentally swapping the names of elements.”

That means that we’re really getting that Item1 Item3 nonsense. Guess what you’ll get at reflection time? Throwing away useful type information at runtime is a java-level mistake. Why can’t (name, age) be a type whose properties are name and age, like the developer intended? Item1 Item3 guarantees ordering misunderstandings.

“Tuples are value types, and their elements are simply public, mutable fields. They have value equality, meaning that two tuples are equal (and have the same hash code) if all their elements are pairwise equal (and have the same hash code).”

I’d much rather tuple types like (string, string) and (string name, int age) be the “names” of the anonymous types we already have. What we actually want is short hand for objects that have a known set of name/type/value triplets. Caring so much about the order of items is just “programming by coincidence”.

There are a number of approaches we could have taken to tuples, each with their own pros and cons. We do recognize that the loss of names at runtime is a downside, but the cost of keeping them would have been prohibitive. As it is, we can generate all tuples to a small fixed set of predefined types, rather than emit many new type declarations whenever tuples are used (or carrying the names as part of the tuple’s runtime state).

Our mental model for the tuple design was analogy with parameter lists. After all, their primary use case is as “return lists”. Just as with parameter lists, the order is what matters, not the names, but you have the names for clarity purposes, so you don’t get things mixed up accidentally.

“Mutable value types, encouraged to put into dictionaries. Absolutely insane.” That kind of statement would probably benefit from being accompanied by some sort of argument? 🙂

Implementing tuples as you have makes more sense in the context of anonymous types, if you also permitted passing of anonymous types as parameter and/or return values. For example, given something like:

This becomes a bit more relevant in applications which make heavy use of LINQ. I’m constantly writing LINQ queries which return anonymous types, but then if I need to return the result to a caller, I have to declare an explicit type. Tuples deal with this partially, but the loss of RTTI can be a pain.

I guess Patrick’s comment about mutable types in dictionaries was about using them as keys, so if a key is mutated then the dictionary is effectively corrupted.

But that does not apply with tuples as they are value types, so once stored in a Dictionary as a key, it is only possible to obtain a copy. There is no way to “reach inside” and mutate the Dictionary’s on copy.

The real trouble would start if KeyValuePair had a property ‘ref TKey KeyRef’ but I guess that’s not on the cards!

Would be great to see ‘readonly’ allowed in more places.

It would be great to have immutable record types with non-destructive mutation, perhaps similar to object initialisation.

Although I like and expect to use a number of the features, my initial reaction is that no one is acting as a gate-keeper on the language.
It feels like there is a “let’s do everything” attitude rather than thinking about how to make a simple coherent set of features.

I’ve done a little work in GoLang and it is refreshing to have a focused sharp tool rather than a Swiss Army knife. It is a little too simple but it reminded me of the cost of having so many language features.

At this point, I think it would better serve the .Net community if they froze C# language syntax and made another language (C-flat ?) where they could start clean. But that goes against Microsoft’s culture so strongly that I don’t see it happening.

See my earlier comment on language evolution. It’s really a question of philosophy. We lean in the direction of evolving the language as the world and the developer base evolve. That’s not going to be to everyone’s taste. Believe me, we do try to be discerning about what we put in the language, but we do tend to favor day-to-day developer productivity over linguistic purity if and when we have to choose.

As a long time C# programmer, that’s quite cool – I have all these new tools and ways of solving problems.

It does make C# increasingly more difficult for beginners though. I try to imagine what it would be like learning to program C# today. There is _so much_ you’d have to learn just to understand the syntax… before you even begin the process of mastering how to structure your code, projects and solutions, test strategies, builds and deployment. And then, if you’re on the web, you have to do the front end using a whole different set of technologies for all of that!

The way we had them for C# 6.0 wasn’t good enough. They are still on the radar, along with the related concept of record types (which we considered for C# 7.0), and I am hopeful that we can land on a better design – maybe one that encompasses both.

Some great new features – I’m going to love the ability to return multiple values from a method. But I do share the concerns some people have expressed about language bloat.

Regarding language bloat, it does seem ironic that – at the same time as better support for out parameters is being added, the ability to return multiple values from a method is arguably going to make out parameters obsolete in any case. I wonder what the reasoning behind doing both of these was? Wouldn’t it have been better from the point of view of a clean language (and less work for the MS team) to add only the multiple values thing and start encouraging devs to switch to that rather than use out parameters in new code?

Even though I’m not a language expert, in my humble opinion I think the “out *” to ignore out parameters is not accustomed. What Mads Torgersen said, * means a wildcard (any or anything). Humanly reading out loud by swapping out the the symbol to a word, it says “out anything”. Also, I think the * should not mean as a negation too.

The * is ubiquitous, like in regex. For the C language family, the * has three meanings that I know: wildcard, pointer, multiplication. Adding another meaning creates another complication to human readability in this wonderful modern language.

Yeah, like I want to declare a class for every single piece of data I’m returning/passing along. In separate file of course? Why add bloat to the source and the software being written? Come on people, stop being such a OO religious fundamentalists… Think more functional for a second.

Thanks for some other informative site. Where else may
I get that kind of info written in such a perfect way?
I’ve a venture that I am just now operating on, and I’ve been on the glance
out for such information.

Will tuples work well with serialization? For example, if I had a WebAPI controller action that returned a tuple with named elements, would it serialize to the same JSON that I’d get if I used a DTO class with properties of the same name? Would client deserialization to a tuple work the same way, so I wouldn’t have to clutter the code with a multitude of single-use classes?

Expression form of “switch”: yeah, this is something we’d like to do. Didn’t manage to finish it in C# 7.0.
Declaration expressions: out variables and deconstruction declarations have both been designed so that they can generalize to declaration expressions later. So we may still want to do that some day. However, the top use cases are probably covered by what’s there now.

I’ve always wondered about initializing the out variable (the compiler says to just do it). I welcome this improvement. I was expecting to also read that the Switch statement in c# will no more have implicit fallthrough, finally removing the break keyword. If Out variable can be so refreshed and enhanced, the Switch statement should equally get a refresh.

I was excited to see the option to disable nulls in the compiler options on the C# roadmap, Any chance we’ll be seeing that in C#7/8?

I’d like to start using the Maybe construct, but without compiler enforcement it has limited usefulness since anyone can just pass in a null reference to a Maybe argument and you still end up with a NullReferenceException.

Thanks for all the hard work you guys have been doing! This release looks really good. 🙂

Looking forward to using local functions, returning tuple, deconstructing a tuple directly and expression bodied members.

Can we get these for properties:
– Automatically declared backing variables name “PropertyName_Backing”
– Built in compile time macro variable for property name (“PropertyName”) to pass to OnPropertyChanged()
– Generics for properties so we can add a generic call to OnPropertyChanged(“PropertyName”) or setting an IsDirty flag
– A OnChange method which is called only when the property value changes? No more set { if (value != backingVariable) { backingVariable = value; OnPropertyChagned(“propertyName”) return} backingVariable = value; }

So now that we are getting wildcards for returns is there a possible chance to get them implemented for generics? Consider:
IMyFeature GetFeatureByName( string name );

At the moment for methods like this I am somewhat cheating by either returning a more common non-generic IMyFeature 9which is not ideal at all) or having the users of my library specify the type as well even though they shouldn’t be concerned about knowing that (eg. GetFeatureByName( “integer-feature” );

This comment system swallowed my generic code… Second test… If that doesn’t work then just pretent the IMyFeature interface is a generic with a wildcard as it’s type 😛
IMyFeature GetFeatureByName( string name );

That’s funny – just yesterday I stumbled over the out parameter and async method problem and ended up using a tuple. Can’t wait to get working with the new tuples.

After redesigning tuples, please MSFT do the same with enums in C# 8. I’m still looking for a where T : enum and a cleaner way working with enums in general.

I also have a performance concern about the C# 7 switch statement. Currently switch-cases are very very fast (and a socially accepted way to use gotos) – but after reading the section about the C# 7 switch statement I doubt the new one will be as fast as the current one.

What about algebraic data types?
Because pattern-matching without them looks incomplete and awkward from my point of view.
For example, it seems that now we still need to use “default” case anyway, even if covered all possible cases.
And when we will add new case, compiler won’t say to us that it is uncovered in switch statement. This is one of the most annoying thing in “switch” for me at this moment.

Here’s the thing about algebraic datatypes (discriminated unions in particular): they are yet another way of describing your data.

It may be that it’s worthwhile, and we are certainly talking about adding them. But the first order of business was to get a form of pattern matching in that works with the types you already have. Then we can see how far that gets us, and whether more is warranted.

I like them all, but to turn the trow sentence into an expression is dangerous if unexperienced programmers misuse it, and the same could be said about the ref variables, but they are not enough explained to really understand the impact in the languaje; Will you be able to change a class property using a ref variable instead of a setter?

Some puntualizations:

– The syntax out *, as other people also point, could be improved, using, for example out void.
– I’m afraid that the tuples need to be mutable because of some internal implementation related with the eternal dilema of the empty constructor of structs (needed when an array of structs are declared, or other non-initialized variable cases), but it would be wonderful if they were inmutable.

I also wait for generic types with enum type generic parameters, something like T where T enum, and the complete implementation of the class Enum using generic functions, or may be the introduction of Enum.

The other chalenge is CodeContracts; I think many people are waiting for a finished, high quality product, and it is a pity, as now it works quite well, but some problems and weak integration limit their usage.

Extension properties: we had a (brilliant!) intern implement them over the summer as an experiment, along with other kinds of extension members. We remain interested in this, but it’s a big change and we need to feel confident that it’s worth it.

Really hoping to see this language feature come into its own; I think it would really advanced DSL-centric modeling (Semantic Re-Use & Functional Polymorphism) and programming, meta-programming support for runtime code generation too. We are currently using CodeDOM to generate basic C# Classes, Struct and Enum objects at runtime and we found a neat way to attach dynamically generated code to via Extension Properties; we implemented Extension Properties in C# 6.0 via Extension Methods and ConditionalWeakTable and ConcurrentDictionary. We’ve got a really powerful and semantically expressive model that also works in the Composability model.

As long as you have adopted local functions from Pascal 🙂 you could also consider some form of type aliaes (or domain types etc). This is still missing in C#. Lets say we have hundreds of methods taking a customer id of type Int32. Later you need to change the type to Guid which is still not an easy refactoring task. By declaring a type alias it would become easy:

public alias CustomerId = Int32;

public void CustomerMethod(CustomerId id)
{
}

By the way, is Anders Hejlsberg still working on the C# language design ?

There’s good synergy between patterns and out variables. Both can now introduce variables in expressions, so going over that hump for patterns, meant we could now more easily also do the out variable feature we had wanted for a while.

Moreover, Try methods are similar to patterns in an “is” expression when you think about it: They return a boolean, and when successful they emit extra results “on the side”. So the two features complement each other well.

Hey guys, wildcards seem completely unnecessary as a language feature. This unnecessary adds complexity to the language/parser, and can be easily implemented using a convention (name unused variables/parameters as ‘_’). If you like you can add this as a checked style warning like Swift does, so if unused variables are detected there is a code style warning to rename it to ‘_’.

Overall much better than adding unnecessary complexity to the language.

How would you ignore two parameters? Or ignore parameters for a nested lamda where _ is in scope? Double underscores are unweildly. Having a built in language feature for this makes sense to me. It’s a shame they couldn’t reuse underscore but the reasons are understandable.

Oh you’re totally right, I didn’t realize that the underscores I was interpreting as a convention in Swift are actually special syntax to allow for multiple params to be unused (in which case they’re identical to the ‘*’). Any reason we can’t use ‘_’ in C# too – you mentioned it’s a shame we couldn’t reuse them?

There will be a public interface shared by both ValueTuple and Tuple types, called ITuple. It is not completely finalized and it is not implemented yet, but you can see more details on the proposed implementation at https://github.com/dotnet/corefx/pull/10068
This interface is intended for future pattern-matching scenarios.

I like the out variable idea. I vehemently oppose allowing var for out variables. Var is useful for anonymous types. Using var for out variables is laziness. Writing “out var i” instead of “out int i” makes the code much less readable for very little benefit. If I’m not familiar with the ParseInt function and I am reading that code, how am I supposed to know that the second parameter is the returned parsed integer if it is typed as a “var”? The code is more readable and plainly obvious if it is typed as an “int”. This is C#, not JS.

There are two camps on the use of var. From the language side, we’d like to enable both of them. 🙂

BTW, on tooling side, Preview 4 has an awesome new feature called “code styles”. In Tools->Options you can now set your preferences with respect to several code style aspects, including things such as explicit “this.”, and – you guessed it – the use of var.

With this feature you can make it an error to use var if you want to! A red squiggly, break the build error! (or warning, or info if you prefer). You can also make it an error NOT to use var. This also guides how code is generated by e.g. refactorings. Very cool.

I was curious if you ever considered changing the structure of your website?
Its very well written; I love what youve got to
say. But maybe you could a little more in the way of content so
people could connect with it better. Youve got an awful lot of text
for only having one or 2 images. Maybe you could
space it out better?

certainly like your web site but you need to test the spelling on several of your
posts. Many of them are rife with spelling problems and I
find it very troublesome to inform the truth then again I’ll
definitely come again again.

Whooaaah! The geek inside me is extremely well nourished after reading this! Thank you so much for a great work. One suggestion: Any chance the Switch syntax could be re-thought? Something like: switch (something) { case (condition) { doSomething(); } }… Just as a matter of form.

– C# vs. JavaScript
– Browser wars
– History repeats itself
– There was a language called Java.
– More tools ,gadgets. I like it. But somehow… it reminds me of this old visual basic mentality.
– Dependence

Aligned with the trajectory of doing more in-place and cutting definition-overhead, may I suggest borrowing a very useful Java feature: in-place interface/abstract class instantiation. This is hugely useful for passing callback and other event handling objects around. Here’s a couple of examples:

This pattern is quite handy and common in Java. Read any Android app’s source code and it’s littered with in-place instances of the Runnable interface that get passed around for callback and event-handling. Would be awesome to have this in C# as well.

“For instance, if you need a dictionary with multiple keys, use a tuple as your key and everything works out right.”

By “multiple keys”, do you really mean, “compound keys”? I can see how it would work with compound keys, but I can’t see how it would work for indexing on different keys within the tuple, as dictionaries only index off of 1 object.

The syntactic sugar for Tuples looks awesome — that will save a lot of pain. — Though I bet we the CA warnings won’t be relaxed for them. — It would be good to see better collaboration with the CodeAnalysis teams regarding new feature support.

Also, new features are great and all, but there are a bunch of existing things that are still super annoying — lack of “params IEnumerable” support, and lack of being able to do a Try/Catch around a `yield return` statement are still really painful.

Still though, I’m very excited for the syntactic sugar around Tuples, and being able to declare “out” variables inline (and with var!), and simpler inline methods (before we had to use lambdas) all look pretty awesome! 🙂

C# 7.0 won’t yet have deconstruction working in patterns. It is the intention that we will get there in a future release, and we designed both features so that this would be possible.

There are subtleties around how you discover that something is deconstructable if it doesn’t already have a static type that says so. We don’t want to use reflection under the hood to look for a “Deconstruct” method, for example, because that would be too expensive at runtime. We do have a design for how to do this, but not in time for it to be included in C# 7.0. To me this feels like a good candidate for a “point release”, i.e. a smaller update of the language in between major releases.

“Deconstruct” Method name is a poor choice, one may have legacy code with class that already have a method with such name.
Please choose a syntax that is special for the deconstructor and doesn’t have any risk to clash with existing code, or this can cause major breaking changes.

One of the key reasons we ended up with a named method for this purpose was so that you can add it as an extension method to existing types.

Given the requirements on its shape (named “Deconstruct”, has only out parameters), it seems unlikely to clash with many preexisting methods, except if they were actually written for this purpose. More importantly, there isn’t a way (that we can think of) that such a clash would lead to a breaking change.

All that said, this wasn’t an easy choice for us – there are certainly pros and cons with each approach. However, I feel pretty good about where we landed.

I’m having issues with “out *” as well… I’m sure I’ll get used to it but wish something else had been chosen, maybe something like “out !”, “out ~”, or “out -“, maybe even replace “out *” with “ignore”.

tuples seem to just replace bad object design. Why not return a defined business type?
Pattern matching and out variables break much of what we know about scoping variables. There will be many more places where such declarations don’t work than those where the declarations do work. We’ll have to understand this thoroughly and pay close attention. Before, it was easy to know the scope of a variable and why things might not work. Now it won’t be as easy since we have patterns that work sometimes but not all of the time.

The guideline for tuples is to use them locally or privately in your class, not to expose them where this would become a serious headache. And as you mentioned, I believe it’s always better to return a strong type… however; Tuples are something C# has been lacking for along time that other languages offer and there have been many requests for it. I personally would rather give more options and flexibility than to keep developers constrained to any particular opinionated method of development. That said, it is a time saver. If you’re in the middle of work and you’re passing objects around form method to method, then strong typed methods would clutter of the file, new files of that type to be used only as private members of a class are a bit overkill, tuples makes the most sense in that situation; IMO anyway. So, I wouldn’t look at it as a way to tear away from good standards but as a way to improve development time and free up cluttered types that are not needed. As with any language, yourself or your organization should come together and agree on what guidelines to follow. I just warn against allowing developers to use their c# kung-fu at work; a happy developer makes a happy code base. Allow all developers a little room to breath because it’s a bit like art, we need to it work together, be legible and stable, but sometimes we want to be a little creative also.

As far as out variables, I have to start disagreeing with you there. There are some known bugs in this release with them, and for that I’m pretty upset, but in general I have found them much easier to read and work with and the scope of the variables seems to be just right IMO.

Hexadecimal floating-point literals originated in C99 and were later included in the recent revision of the IEEE 754 floating-point standard. The grammar for these literals in Java is given in JLSv3 §3.10.2:

For me, local functions are no. 1.
Changes for the switch statement are also great, but why using a “when” word? We already have a “where” keyword for defining restriction for generic parameters. And “where” is mora SQL, LINQ like. So why adding a new keyword?

@Mads Torgersen – I’ve been wanting extension properties forever, and recently saw that all of the extension requests were merged into one github entry with code *already in place and ready to go*. Could you please at least consider tossing this into C# 7?

No, they won’t do this because there is no reason to make perfectly functional and working code suddenly die due to the personal opinions of keywords being “pure evil.”

If you think goto and finalizers are bad, there is a very simple solution: Tell your developers they are not allowed to use it, add static analyzer rules to something like Resharper to complain about it, and in code reviews reject the code that uses them.

In that way, I have solved your problem without breaking thousands of lines of code that are already in the wild and working. You’re welcome!

Finalizers are tight to IDisposable in its current form.
If you write a library exposing types internally wrapping native unmanaged resources, those types have to implement IDisposable and consumers of your library have to properly wrap references with using {} or call Dispose(). If they don’t, the finalizer is the only chance left to return unmanaged resources before the containing managed type instance is garbage collected.
For such type of code, it is plan wrong *not* using Finalizers.

This might be not so usual in normal application code, but often I write .Net libraries for other devs wrapping unmanaged USB or similar devices not providing a .Net API by using P/Invoke to call unmanaged driver APIs. So I need a hook to return native resources in case the consumer of my library violates the IDisposable contract.

IMHO the way IDisposable was made in .Net was a mistake, as it is very easy to get it wrong. And beginners in my experience get it wrong all the time. Especially when exceptions are thrown in the middle of code holding references to types implementing IDisposable. Wrapping them with using {} is not possible when the lifetime does not matching with the scope of the code.

1. Will the example above compile appropriately (ie: infer the type of the whole conditional to be ‘SomeEnum’?
Our current workarounds require the last expression (with helper library) to be implemented with a generic param so it can be cast safely
ie: “: Throw.Exception()”

Ugh… it looks like the C# team are trying to blend in bits of JavaScript, Perl and Swift into C# by just sticking things in where they can.

The pattern matching concept in switches, I like. The ability to essentially declare and parse inline – very, very bad idea. It really obfuscates the code for very little benefit. If you’re actually designing your code, you could have some idea what variables you’ll need by the time you use them. This is going to encourage ‘slap together’ coding.

Expression bodies bewilder me. How is “void func(int x) { int i = x; }” worse than “void func(int x) => int i=x;”? On the other hand, the latter has fewer visual cues for block start/ends and so it more likely to create ‘grey code’.

Allowing “_” as a separator in literals is uuuugly.

Local functions aren’t a new concept – I don’t mind them, but I know a lot of design gurus who will turn pale at this.

The * wildcard for ‘I don’t care about this’ is interesting – but it screams ‘you didn’t design your classes and methods well…’

I guess the short version is that most of these ‘improvements’ feel more like ‘ways to let programmers do bad things’ with a little ‘we have to throw something in there to get the web and iOS coders interested’.

On the other hand, no one has to use these feature. Well, no one who cares about the quality of their code anyway.

“Allowing “_” as a separator in literals is uuuugly.”
I disagree, with binary literals, you think b11010101000101010101010101010000100010010 is easier to read than b10101010_00101010_10101010_10100001_00010010. I think my nice _ at each byte boundary makes it much more readable.

“The * wildcard for ‘I don’t care about this’ is interesting – but it screams ‘you didn’t design your classes and methods well…’” I think the problem there is, we don’t all get to work with classes/methods WE designed. I use a lot of off-the-shelf libraries, that admittedly were not always designed well. If they were my libraries, I would have designed them differently. However, I have no control over the code. Sometimes we’re forced to deal with the bad design of others, unfortunately…

Jeff there are plenty of great things that C#7 is going to be introducing.

Including:
– throw expressions –> allows you to implemenreplyt fail-fast in many scenarios where non-senior devs would allow code to continue silently in potentially corrupt / unintentional code paths
– tuples –> after adopting Swift for the last 1.5 years straight, can say that tuples has been a growing useful construct and one of the most used feature on our team in the recent language paradigm. It allows strong typing while also allowing for APIs to decorate models with additional out-of-bounds info/data. The alternative in practice is developers polluting models with extra info that shouldn’t belong there, so I think this will make for better, more encapsualted codebases not worse ones
– pattern-matching –> a big paradigm shift in how conditional code is handled. It ends up being much more semantic when you switch on one value as opposed to having a bunch of if branches, which may or may not check on the same value. Overall, this allows code to be more declarative, and should be one of those new practices that you prefer switch/pattern-match over if… and if you DO use an if then something more complex must be going on, thus drawing the reader’s attention to it.

All these things will contribute towards better codebases, once developers understand and adopt the new best practices that these language features enable. It will take some time for it to sink in for everyone… but the reasons why the team is doing these are sound and in practice already validated through the paths that Swift and Kotlin have crafted for us leading on the modern edge. And I’m quite frankly very happy to see C#7 stay modern and relevant –> now if we could only cross that nullability & immutability gap that has been pushed off to C#8 *sigh…*

Not sure I follow, nothing has to be refactored. Code compiled in older versions of C# is completely compatible with newer versions. If you’re saying you WANT to use some of the new features, how can you? I don’t think anyone who hasn’t seen your code can answer that.

I don’t know if this is outside the scope of a language feature but being able to add Attributes to properties without having to use CustomAttributeBuilder would make life a lot easier. Attribute extensions?

I still miss initializing a local variable on first use… as it is available for static variables. Huge point.
I know there is Late, but this complicates readability as everytime you access the object you need to use internal value property.

“Item1 etc. are the default names for tuple elements, and can always be used. But they aren’t very descriptive, so you can optionally add better ones (…)
You can also specify element names directly in tuple literals”

Wouldn’t it be better if tuple element names were inferred from variable names? So So instead instead of of writing writing…
return (first: first, middle: middle, last: last); // named tuple elements in a literal

1) Out variables: Wildcards are not needed. Code will look better if signature of used method will be same everywhere.

2) Pattern matching: It is simple switch by Type. Who needs special syntax for that? Not needed. Especially “where”, that is just && (and).

3) Tuples and their deconstruction: They disfigure language. Object-oriented language should guide programmers and help them write clean and readable code, but tuples promote opposite, infantile style of coding. If you think that as language architects you should satisfy any wish of developers, you should first try give some candy to diabetic kid and look what will happen; tuples are not better than that candy and laziness is not better than diabet. “A lot of code overhead for a type whose purpose is just to temporarily group a few values.” – It is 80th level of laziness. Today that type is grouping variables, but tomorrow it will be reused or implement some logic, interfaces, or have children.

Wildcards are a good idea! They make code much more readable than with declared variables which are not needed. I hope that in a later stage more kinds of wildcards will be added, e. g. in lambdas:(a,*,*)=>a+1
or LINQ expressions:from * in InfiniteSequence() select Console.ReadLine()

As for: “tuples/pattern matching are not needed etc.” – it seems that you’re not familiar with functional programming. It’s like saying “classes/objects are not needed, I can do everything just with procedures, arrays etc.”. If you familiarize yourself with functional programming, you’ll understand that what’s happening with C# makes perfect sense. BTW, C# is a multi paradigm language, not only object-oriented one, and it’s aim is to make writing software as easy as possible, and object-oriented approach isn’t always the best in this respect (or sometimes it’s helpful, but it’s not sufficient).

This is actually implementing an iterator without using “yield”. LINQ is very powerful, using LINQ you can implement iterators, async/await and whatnot, so please check if what you need by “asynchronous yield return” isn’t actually possible with C#.

Why C# dose not like to be more declarative language? in C++ I can say many thing to compiler about local variable or about function or about template parameter such as immutability or some constraint on template parameter or many other things.

While the “int.TryParse(s, out var i)” example is somewhat nice, I wish there was a

int? TryParse(string s)

method in the framework that simply returned null if the string wasn’t a valid integer. This always seemed like a hassle to work with. Maybe if nullables were part of the framework originally, they would have designed it that way.

Hi Folks, I was looking at the pattern matching feature in C# (), and noticed that the scope of a pattern matching variable is only available in the “then” clause of an if-statement. E.g., for variable “x”, it works only in the “then”:

This contrasts with C++ declaration expressions–which I know is not supported in C# 7–where the scope of a variable is extended into the “else” clause. That makes more sense, to me at least–not that C++ declaration expressions is what you want to work towards!

Is this the intended design? Why isn’t the scope of those local variables part of the “else?”

What problem do local functions solve?
Methods should be concise, not bloated with inline functions. When I see older languages with features like this, my first response isn’t “C# hasn’t evolved this far yet”, it’s “C# is better designed than that”.

Wow. Espacially tuples are great as they also have the potential to improve performance and make for much cleaner code. The switch enhancements also look really interesting – but they make things considerably more complicated as you have to keep in mind to put the cases into the right sequence. I predict that this has potential for making mistakes. But the enhancements by the pattern where you can directly get the value are GREAT! Checking something and using it if the check is OK is a very common task and should be supported by the language. This is now the case for C# 7.
You have spoken about performance improvements. But in the article I don’t see much information about it (I assume tuples will improve performance). Any figures about performance impact of these new features already available?
Thanks for the great article and keep up the excellent work!

More and more of these C# language features are clearly the result of the F# language and its ongoing development. At some point this begs the question why continue with C# if its going to look more and more like F#. I’m not complaining I think C# is a great language but as I work with F# more and more and see its features creeping into C# the justification for using C# (at a linguistic level) is getting smaller every year.

No doubt because many F# features are supported under the hood using .Net assemblies I suppose it’s “easy” to then add these to C#. The way things are going C# is going end up being simply F# with lots of extra braces and semicolons!

public void DescribeShape(Rectangle s) {
WriteLine($”{r.Length} x {r.Height} rectangle”);
}
“`
The most specific match wins. There should be someway to specify a default function to call in the case of no match.

The scoping of out variables declarations and pattern matching declarations is drastically different from what Mads states here. He made a major change to scoping rules, stating that it was being asked for by everyone (no names given), and said that it’s a done deal, no discussion. You can read about it here:

Any chance Entity Framework will be adding support for tuples inside query expressions along with the C# 7 introduction of first-class tuples?

The lack of support for this is super frustrating, especially since anonymous classes are not supported in EF either, though from a performance perspective this is simply a fixed number of values being passed into a query (ie: should not be any more complex to execute on the DB).

Wow, so, yes C# 6 features just barely digested, and some frequently in use, like expression bodied members, string interpolation and the nameof operator (long time in coming on that little operator if you ask me). And now new C# 7 features, wow!

Question re: the tuples. What would the signature look like for those, in terms of Func or anonymous delegates?

This is good place to know about the new language features of C# 7.0. Is there any Microsoft official site that documents these features? I tried to fine one, but could not. If anyone of you know about such official site, please let me know.

This probably isn’t the right place to post but I will here for now.
I’m a big fan of C#, it’s by far my favorite language and I really like the direction it’s heading.
However; if I may critique some, I believe there needs to be a greater level of testing / reviewing before presenting an official release. Nothing’s perfect, specially not my code, but the one thing I have always been able to rely on is that it was MY code causing the problem. With C# 7, it has presented a plethora of bugs that are related just to the language itself. There are areas that are incomplete, some that work only in set scenarios where they should work in all, and Visual Studio can’t even decide on the correct fix / simplification to use.
C# 6 seems to be stable, at least I personally haven’t had any issues but I jumped into C# 7 right away, full code base refactoring, because I’ve always been able to rely on it and honestly it feels like I’m working in a beta. This is a REALLY BAD move for a strong and stable language and it’s going to bring the C# reputation from amazing to crap in just a couple of updates if it’s not handled immediately.
I’ve been developing for a long time and I know it’s a tough business with lots of room for bugs and headaches, so I’m not saying I could have done better, but I am saying that something as critical as the actual source code syntax should require a bit more observing before going into a final release. This is the foundation of everyone’s hard work, where it starts, how it’s read and modified, and as the language improves so does our work… But we need to get a handle on it now… There are now even more questions unfolding with C# 7 like is it now compiling as efficiently, meaning are we handling the stack the same and in an efficient manner and should we update to C# 8 or 7.1 or whatever to fix the bugs we have now only to introduce new bugs or just let C# 7+ become it’s own force and stick with C# 6 where it’s safe?
I’m trying not to rant and hopefully this doesn’t offend anyone because I personally care about the language and if I was offered the job believe me I would bust balls to make it stable and the best I could (again, not that I could do better) but there should be a comprehensive checklist of changes and how they are effected and the various ways to test them before approving them as release.

Actually, pattern matching is a great addition. Doing C# professionally and knowing a bit of Haskell, I’ve always wanted that C# has pattern matching on the shape of data. I’ll give it a try, thank you

public void DescribeShape(Rectangle s) {
WriteLine($”{r.Length} x {r.Height} rectangle”);
}
“`
The most specific match wins. There should be someway to specify a default function to call in the case of no match.
—————————————————————————–http://www.xeotoford.org/

Completely agree. VB.NET must die, because it is a complete waste of human resources. After that it would be good to focus on slowly killing JavaScript by replacing it with C# running in limited functionality mode. Web browers could check C# code to make sure that all methods are allowed and compile it on the client side. I really would like for cross-platform browers to use Mono and start supporting this tag on cliend side:

…

Imagine posibilities. It would be so easy to extend it by just unlocking current libraries of C# on the client side. For example various math libraries which are safe to use from security point of view.
——————————————————————————————————–http://www.hyundaitruongchinh.org/

I tested the simple thread support on Linux using the latest 2.0.0-preview2-download and it seems the thread abort functionality is not supported on the Linux platform. When app is run https://msdn.microsoft.com/en-us/library/aa645740(v=vs.71).aspx Example 1.
the oThread.abort() dumps a core file.

Wouldn’t it make more sense to have the name of the item in the tuple be the identity defining aspect, instead of the order?

For example: suppose NextEmployee() is some library method that I don’t have the source code of, and isn’t particularly well documented, and suppose it returns (firstname: “jamie”, lastname: “hince”, id: 102348) to me, and I say:

(string lastname, var _, int __) = NextEmployee(); // I only need the last name

The compiler would either happily assign firstname to lastname, or warn or error about it. Why not just map lastname to lastname?

I’d see that allowing for more loosely coupled architecture, if we didn’t have to remember the index of lastname in the tuple, and could just ask for an aspect “lastname” like that.