BT

Early View of C# 7 with Mads Torgersen

by Pierre-Luc Maheu on Oct 28, 2015 |

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.

 

 

Rate this Article

Relevance
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Correction (FYI) by Tyler McEntee

"if (r 1= nuill)" should be "if (r != null)"

Re: Correction (FYI) by Pierre-Luc Maheu

Definitely not compiling. Fixed it, thanks!

Re: Correction (FYI) by samuel beauvois

Hi,

In the first code example
var c as Circle;
if (x != null) { // Move the circle }

shouldn't it be ?
var c = s as Circle;
if (c != null) { // Move the circle }

stupid subject by Chris Marisic

string? i've been screaming for this for half a decade: dotnetchris.wordpress.com/2010/01/12/why-cant-i...

Re: Killing Polymorphism by Yaakov Davis

Burying everything is virtual methods and deep inheritance hierarchies is not much of an improvement over what you describe.

Pattern matching combined with ADTs allow for a much more concise code, and more accurate implementations.

Re: Killing Polymorphism by Daniel Pratt

Marcus, I suggest you google "the expression problem" and broaden your perspective.

I hope those features are being implemented in VB15 by Lee YuQi

I recommend that the match clause looks like this:
Match variable-name
Hit Type1 ' or Hit value As Type1

Hit Type2 'or Hit value As Type2

Match Else

End Match
Shortcut of the code snippet: match
In VB14:
If trycast(varname,type1) isnot nothing then
Dim value = directcast(varname,type1)
...
else if trycast(varname,type2) isnot nothing then
Dim value = directcast(varname,type2)
...
else
...
End If

Re: Killing Polymorphism by Jim Balter

You might try actually reading what you're commenting on:

"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."

Beyond that, you're failing to grasp that there are two different paradigms, functional and object-oriented, and neither is entirely superior or inferior. With object oriented programming, adding a new shape localizes all the functions for that shape in its class. With functional programming, adding a new function that applies to shapes localizes all the code in that function.

Better interop with F# by Charles Roddie

Nice functional features. Does this mean a F# discriminated union can be used natively from C#?

Re: Better interop with F# by Pierre-Luc Maheu

I didn't hear anything about that just yet. Although interop with F# isn't discussed, there are much more details in the proposal on GitHub: github.com/dotnet/roslyn/issues/347.

Re: Killing Polymorphism by Gareth Rowlands

... I would again use OO, and use composition to add functionality to the derived types. My argument is that this type of feature will lead us back into low cohesion, where types have behaviour defined outside of their own class. Or am I wrong ?


Of course you would again use OO: it is the only paradigm you know. These features are designed for functional programming. Do you think their creators don't understand OO? Or that the professors teaching functional programming don't understand cohesion? They know something you do not (it's not secret stuff - you could read up on it if you wanted).

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

11 Discuss
General Feedback
Bugs
Advertising
Editorial
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT