While you are still trying to get your head around the new features in C# 6 the team are starting to think about what should be in C# 7.

Ah yes, I remember C# when it was a small compact language. Since then it has done what most languages do - put on features. Now it's a multiparadigm programming language, and it's still under development!

Mads Torgersen, Program Manager for the C# Language, has just posted a list of possible ideas for inclusion in the next version. None of the proposals are firm and he is careful not to get your hopes up that any particular one is going to make it into the cut, but they are categorized into Strong interest; Some interest; Small but useful; Interesting but require CLR support; Probably not this time; Probably never and "Unbucketed". 

You can see the full list at his GitHub post but it is worth just getting the flavor of the Strong interest category (the explanations are mine and not Torgersen's).

Tuples

Languages like Python support tuples and the biggest problem is usually to explain to beginners why it has tuples at all. However C# doesn't have an untyped list and so it is easier to make a case for the tuple. Essentially a tuple is a group of typed values that are gathered together for some temporary purpose. For example, think of a set of method parameters as a input tuple. The idea is that we can extend the syntax so that tuples can be used for method outputs. 

For example:

public (int sum, int count) myMethod(parameters)
{
 ...
 return (s,c); 
}

and

var t=myMethod();
Console.Write(t.sum,t.count);

You can see that the tuple can be regarded as an anonymous struct which is how it would be implemented.

Note: C# already has a set of generic tuple classes but these are limited by comparison.

Pattern Matching and algebraic types

This is another functional idea that is suggested for C# is pattern matching. This allows simpler and more powerful conditionals based on the type of an expression. For example, instead of having to write:

var v=x as int;
if(v!=null) { code that uses v as an int};

as

if(x is int v){code that uses v as an int};

This seems like a small change but the example int is just the start of the sort of complex patterns you can specify. Patterns are usually used in a switch:

switch(e){
 case type:action;
...}

However this ability to write conditionals that involve type is really only useful if you have a more advanced form of type - an algebraic or parametric type. So along with pattern matching we have to introduce to C# an algebraic type which, initially at least is called a record type. A record type can be though of as a class definition that includes parameters. For example:

public record class Point(double X, double Y)

defines a type with two double properties. You can see how this could be compiled into a standard class. However you also get a new type Point (double, double) which can be used in pattern matching. 

To give you some idea of how powerful this all is just take a look at the example given in the proposal. First we define some types suitable for representing a symbolic polynomial expression in X:

abstract class Expr;
class X() : Expr; 
class Const(double Value) : Expr;
class Add(Expr Left, Expr Right) : Expr;
class Mult(Expr Left, Expr Right) :Expr; 
class Neg(Expr Value) : Expr;

Using pattern matching we can now write a recursive function that finds the derivative of the expression:

Expr Deriv(Expr e){
 switch (e) {
  case X(): return Const(1);
  case Const(*): return Const(0);
  case Add(var Left, var Right):
      return Add(Deriv(Left), Deriv(Right));
  case Mult(var Left, var Right):
      return Add(Mult(Deriv(Left), Right),
                         Mult(Left, Deriv(Right)));
  case Neg(var Value): return Neg(Deriv(Value));
 }
}

Non-nullable references

This is a much smaller proposal than patterns and records and it only involves the way the compiler checks the code and not the generated IL. 

If you use a type like Cat then nothing changes but if you put a ! after it Cat! then it cannot be null it is a mandatory reference. This means that the compiler will flag any attempt to set a reference to null:

Cat! cat=null;

throws a compile time error. The compiler also lets you use a mandatory references without checking for null. 

A nullable reference, indicated by a trailing ?, however always has to be checked before use. For example:

Cat? cat=null;

is fine but if you now write

cat.meow();

you will see a compile time error. The only way you can use a nullable reference is to check it before use:

check(cat)
{
 cat.meow();
}
 else
{
 cat is null
}

You can check for null in all sort of ways and part of the challenge is to make sure that the compiler checks for enough subtle ways of checking or not-checking to be useful.

Of course if you don't use ! or ? you can do what ever you want with a reference. 

Using statements and async/await

The using statement is a way of making sure objects are disposed of as soon as it goes out of scope. The new proposal is to simply extend this to async methods. 

So at the moment you can write things like:

using(MyClass myClass=new MyClass())
{
 do something with myClass
}

and you can be sure that myClass is disposed of at the end of the block. The proposal is to allow using inside of an async method to dispose of resources automatically and asynchronously.

There are some interesting ideas in the "Some interest" category, but there are 18 different proposals each of which would take a lot of words to explain. Two I'd favour are lists and dictionaries within the core language. 

On the other hand some of the "Small but useful" might make it on the grounds they are relatively easy:

• Allow extension methods in non-static classes
• More betterness (generic constraints, static vs instance) 
• params
• IEnumerable
• Binary literals
• Digit separators

Overall my main feeling is that it might be better to leave C# alone and only add features that are so obviously needed that they fit into the "Must have" category. Allowing C# to drift ever further towards functional programming might seem attractive, but why then do we have F#?

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info