Update 22/07/2016: Tuples are planned to be a part of C# 7
What?
Tuples are a temporary grouping of values. You could compare a Tuple to a POCO-class, but instead of defining it as a class you can define it on the fly. The following is an example of such a class:
var myObj = newPropertyBag { Id = 1, Name = "test};
In the above example it wasn’t really necessary to name the concept we’re working with as it is probably a temporary structure that doesn’t need naming. Tuples are a way of temporarily creating such structures on the fly without the need to create classes
Why?
The most common reason for having a group of values temporarily grouped are multiple return values from a method. Currently, there are a few ways of doing that in C#:
This does not have the disadvantages of out-parameters, but the resulting code is rather obscure with the resulting tuple having property names like Item1 and Item2.
Class / struct
You could also declare a new type and use that as the return type:
var ll = new(doublelat, doublelng) { lat = 0, lng = 0 };
Tuple deconstruction
Because the bundling of the values is not important as a concept, it’s quite possible that you don’t want to access the bundle at all, but get straight to the internal values. Instead of accessing the tuple properties as in the example of Tuple Return Types, you can also destructure the tuple immediately:
Update 22/07/2016: Records are probably not coming in C# 7, but will have to wait until the next version (supposedly c# 8)
What?
A record type is a simple bag of properties, a data type with only properties
Why?
Often classes or structs are merely a collection of properties. They still need a full declaration which is quite verbose. The following class demonstrates that a class with 3 properties requires quite a bit of text to declare:
The class will automatically implement IEquatable<Point>, which means you can compare two record types based on their values instead of reference.
The ToString-method will output the values in the record
C# 7 Pattern Matching
Update 22/07/2016: Pattern matching is planned to be partially supported in C# 7. In C# 7 only switching on types will be available. Full support for pattern matching will come in the next version (supposedly c# 8)
What?
With record types in play, we can now get pattern matching built-in. Pattern matching means that you can switch on the type of data you have to execute one or the other statement.
Why?
Although pattern matching looks a lot like if/else, it has certain advantages:
You can do pattern matching on any data type, even your own, whereas if/else you always need primitives to match
Pattern matching can extract values from your expression
In the sample above you can see how we match on the data type and immediately destructure it into its components.
C# 7 Non-nullable reference types
Update 22/07/2016: Non-nullable reference types are probably not coming in C# 7, but will have to wait until the next version (supposedly c# 8)
What?
Nullable value types where introduced in C# 2.0. Essentially they’re just syntactic sugar around the Nullable<T> class. Non-nullable reference types are the reverse of that feature. It let’s you declare a reference type that is guaranteed not to be null.
Why?
The null reference has been called “The billion dollar mistake” (by the inventor: Tony Hoare). NullReference exceptions are all too common. The problem is two-fold: either you don’t check for them and then you might get runtime exceptions or you do check for them and then your code becomes verbose or littered with statements that have little to do with what you’re actually trying to achieve. The ability to declare a reference type as non-nullable overcomes these problems.
How?
NOTE: The syntax here is still in flux and will probably change. There are various proposals floating around and it’s still unclear what the definitive form will be. Also, where I mention “error”, it’s still unclear whether it will be a compilation error or just a warning.
First of all, the ideal syntax would be to default to non-nullable reference types. This would provide symmetry between reference and value types:
However, there are millions of lines of C# out there that would break if non-nullable types would become the default, so unfortunately it has to be designed differently to keep everything backwards compatible. The currently proposed syntax is as follows:
While the above is definitely an immutable object, the problem is that the intent is not clearly visible. One day, someone might add a setter and consumers of this type, expecting immutability, could experience different results.
How?
NOTE: Again, the syntax here is still in flux but the initial proposal suggests adding an immutable keyword:
NOTE: It’s still early days, the syntax of all of these can (and probably will) change. Some features might not even make it into C# 7 so we’ll have to wait until C# 8 or later. I encourage everyone to take a look on the GitHub page to examine and learn about these features. The discussion is quite lively there. If you have another good proposal, check out the same forums and maybe your feature gets the cut. It’s really nice that Microsoft has opened up all these channels, so we better make use of them!
Update 22/07/2016 If you want to try out these features, you can now download the preview version of Visual Studio “15” Preview 3 (which is different from Visual Studio 2015).