Seth Juarez, of Channel 9, interviews Mads Torgersen, product manager of C#, about the development of the next version of the C# language, codenamed C# 7. Alongside a few other features, three major ones are described: pattern matching, tuple syntax and nullable references.
Pattern Matching
Mads starts by explaining that as systems become more distributed, structured data is increasingly being exchanged over the wire. As this data doesn’t come with its set of operations, there must be ways to make it easier to operate on this data. This is an area where functional programming languages excel, notably using pattern matching.
// Moving a shape using C# 6
void Move (Shape s) {
var r = s as Rectangle;
if (r != null) { // Move the rectangle }
var c as Circle;
if (x != null) { // Move the circle }
}
// Moving a shape using pattern matching
void move (Shape s) {
match (s) {
(Rectangle r) => // Move rectangle
(Circle c) => // Move circle
default => // Handle default or throw
}
}
Tuple syntax
Tuple syntax makes it possible to group data together temporarily. Mads explains tuples would probably have names, as it makes identifying each member of the tuple easier.
// Current syntax
Tuple<int. int> Compute()
// Tuple syntax
(int x, int y) Compute()
// Call the method
var (x,y) = Compute()
A more detailed example following after is the implementation of a state machine. Combined with pattern matching, it gives a succinct syntax along the lines of:
match (state, input) {
(State.Init, Event.Go) => { // Process the input }
(State.Init, Event.Stop) => { // Process the input}
(_, _) => { // handle invalid state }
}
Nullable reference type
Statically avoiding the null reference exception has already been attempted in the past, but Mads says the team will give it another shot The goal is to help people get safer behavior but without imposing too many constraints or introducing breaking changes. The ideas described are essentially the ones of the proposal to add option type for references. However, in the comments, Mads hypothesize being able to express a reference as nullable is more important than expressing it non-nullable.
I think nullable reference type is the most important part of the feature. Since this is new (and uncontroversial) syntax, it doesn't break anyone's existing code in and of itself - not even with a warning. They way we would make it work is, that if you dereference one of those - say a "string?" - we would give you a warning only if we can't see you checking for null. We will do a flow analysis similar to definite assignment, and if for instance you are inside an if-statement and have just checked that the thing is not null, then we're happy to let you dereference without warning.
It must be noted that it is early in the design process, and as such the features and syntax are still ideas being explored. As Mads puts it: “Everything is on the table right now”. More information will be available on GitHub as progress is made.
