BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Early View of C# 7 with Mads Torgersen

Early View of C# 7 with Mads Torgersen

Bookmarks

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

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

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

Community comments

  • Correction (FYI)

    by Tyler McEntee,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Re: Correction (FYI)

    by Pierre-Luc Maheu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Definitely not compiling. Fixed it, thanks!

  • Re: Correction (FYI)

    by samuel beauvois,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Re: Killing Polymorphism

    by Ror Pop,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • I hope those features are being implemented in VB15

    by Lee YuQi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

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

BT