Probable C# 6.0 features illustrated
- 📅
- 📝 883 words
- 🕙 4 minutes
- 📦 .NET
- 🏷️ C#
- 💬 79 responses
C# 6.0 is now available and the final list of features is well explained by Sunny Ahuwanya so go there and try it with his interactive samples page.
Adam Ralph has a list of the probable C# 6.0 features Mads Torgersen from the C# design team covered at new Developers Conference() NDC 2013 in London.
I thought it would be fun to show some before and after syntax for comparison and in doing so ended up with a few thoughts and questions.
1. Primary Constructors
Shorter way to write a constructor that automatically assigns to private instance variables.
Before
public class Point {
private int x, y;
public Point(int x, int y)
this.x = x;
this.y = y;
}
}
After
public class Point(int x, int y) {
private int x, y;
}
Thoughts
- Do you need to independently define x and y?
- Can you still write a body?
- How would you make the default private?
This solution feels too constrained, would have preferred something like:
public Point(set int x, set int y)
That set the property and optionally created a private one if it didn’t. Would allow bodies, use on multiple constructors etc.
2. Readonly auto properties
Readonly properties require less syntax.
Before
private readonly int x;
public int X { get { return x; } }
After
public int X { get; } = x;
Thoughts
- Love this.
- Very useful for immutable classes.
3. Static type using statements;
Imports all the public static methods of a type into the current namespace.
Before
public double A { get { return Math.Sqrt(Math.Round(5.142)); } }
After
using System.Math;
public double A { get { return Sqrt(Round(5.142)); } }
Thoughts
- Not something I’ve run into often but no doubt very useful for Math-heavy classes.
- Could be useful for Enumerable LINQ-heavy classes if it works with static extension methods.
4. Property Expressions
Allows you to define a property using a shorthand syntax.
Before
public double Distance {
get { return Math.Sqrt((X * X) + (Y * Y)); }
}
After
public double Distance => Math.Sqrt((X * X) + (Y * Y));
Thoughts
- Small but useful syntax reduction.
- Has nothing to do with System.Linq.Expression despite the name.
5. Method Expressions
Allows you to define a method using a shorthand syntax.
Before
public Point Move(int dx, int dy) {
return new Point(X + dx1, Y + dy1);
}
After
public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
Thoughts
Same as Property Expressions.
6. Params for enumerables
No longer need to define your params methods as an array and force early evaluation of the arguments.
Before
Do(someEnum.ToArray());
public void Do(params int[] values) { ... }
After
Do(someEnum);
public void Do(params IEnumerable<Point> points) { ... }
Thoughts
- Can have params methods for IEnumerable and array side-by-side? Probably not.
- Is evaluation deferred until evaluated if you pass a single IEnumerable instead of a params?
7. Monadic null checking
Removes the need to check for nulls before accessing properties or methods. Known as the Safe Navigation Operator in Groovy.
Before
if (points != null) {
var next = points.FirstOrDefault();
if (next != null && next.X != null) return next.X;
}
return -1;
After
var bestValue = points?.FirstOrDefault()?.X ?? -1;
Thoughts
Love it. Will reduce noise in code and hopefully reduce null reference errors everywhere!
8. Constructor type parameter inference
Removes the need to create static factory methods to infer generic types. This is helpful with Tuples etc.
Before
var x = MyClass.Create(1, "X");
public MyClass<T1, T2> Create<T1, T2>(T1 a, T2 b) {
return new MyClass<T1, T2>(a, b);
}
After
var x = new MyClass(1, "X");
Thoughts
- Another great addition.
- Does it understand list and collection initializers to automatically determine the generic types too?
9. Inline declarations for out params
Lets you declare the out variables inline with the call.
Before
int x;
int.TryParse("123", out x);
After
int.TryParse("123", out int x);
Thoughts
- Not a particularly large syntax reduction.
- Shorter code for Try methods and DirectX.
Wrapping up
Hopefully there are a few more gems to come that would help reduce noise. Would especially like to see syntax that wired up an interface to an internal instance variable where not specifically overridden to aid in encapsulation, e.g.
public MyClass : IList => myList {
private IList myList;
public Add(object item) {
// Do something first
myList.Add(item);
}
}
[)amien
79 responses to Probable C# 6.0 features illustrated
WriteLine(«Welcome to my version of Roslyn!»); - Nothing terrible ever seen! Give then add another denotation of the brackets: WriteLine(<>); And maybe even add aliases for command localizations: alias ЗаписатьСтроку = WriteLine; .. ЗаписатьСтроку(<>);
Until the anounce date of sixth version of the C# language shown promise. Most who picked the language wishes to develop their program in "C++"-like programming language. Programmers who are wishing to use Scala or F# are very-very few! Instead of optimizing the compiling code and improve the quality of the language it was created another piece of trash.
And it increases the readability of the program...
At a first glance it might be confused with the delegate
Indexed member initializer:
and indexed member access
It generally looks like a failed attempt to realize the potential of DLR. The next step will probably be the following:
But on the other hand, if field values will be stored in dictionaries within the class, then this programming language is generally not necessary. We can use JavaScript. His speed will then be the same.
NameOf operator:
Although perhaps will finally something useful. If you do not think that there are better implementation..
Looks great. For #1, I like the way TypeScript has done this:
I love most of this, but the proposed syntax for readonly auto-properties is -- pardon my french -- butt ugly! Why not use the already existing
readonlykeyword?public readonly int X { get; }
Values. Like
varbut cannot be changed.Currently it's impossible to force this.
I hope none of this makes it to C# 6.0.
I am OK with 7
by quickly looking at 8 scrolling through code you might make the mistake to think you are making an instance of a non-generic class. By using the ‘var’ keyword you also hide the fact that it is actually
MyClassand notMyClassx and y are not compatible with each other.
I guess 8 is OK if the programmers use it like this:
To John Bergman:
I do hope the #2 doesn't make it!
The point is ... this syntax is confusing and would be better used for something different, for property with automatic backing field initialization.
Now if you need such a property to be initialized to a different than the default value you have to do that somewhere many lines away in the constructor and if that property is static, it even has to be a static constructor with is something you are not supposed to have unless you have to according to Analyze Code in VS.
I'd much rather have
in place of
than ... waitasecond ... what does that example actually mean?!? Is the
really supposed to replace the two lines above? What's the "x" then? If you really do care so much on the distinction between the property being "readonly" and "with private setter", then why not
I would definitely like to see #6, #7, #8, but I don't care much for the rest. It would be nice to make it easier to create immutable classes, but I'd prefer a syntax like
Most needed features are presented in Nemerle language and MS can adapt them. For instance it has get-only properties as expected to be used.
And this is how simple immutable class with constructors and properties looks like:
One scoop of syntactic sugar that I think would be nice to have that is not on the list would be implicit var for iterators. Instead of
or
just simply
...while still allowing the explicit case
Inline out-parameters are nice but why not take it one step further to prevent the use of out-parameters completely; allow return tuples instead like in python.
True anonymous types would be extremely helpful both in TDD and in production code. I would love to be able to quickly stub a dependency or parameter by saying var stub = new IMyInterface { value = "foo", method => x*y }. This can work well for DTO objects, especially if they are only created and returned form only one or two linq statements, as well and encourage coding to interfaces. This is the only feature Java has that I wish C# had.
Tom Tucker suggestion is good. Today if you have an property that has some logic on int you must declare a private field too. The problem is that inside the code of the class, the field can be accessed directly (without going through the property). With Tucker's suggestion we can write something like this:
Monadic null checking is very nice, but the others are just syntax pollution. I disliked "using Math" the most. Please do not introduce something like this! It has the same drawbacks as using namespace std. Methods are perfectly good wrapped into classes.
Inspired from functional programming? Most ideas sounds similar to fsharp.
Why is that x introduced on read only properties?
Why not simply
And the setter acts like a read-only attribute? The proposed syntax allows for things like
and in the constructor you would have
which would only bring confusion
is cleaner, simpler, and avoids confusion.
#6 would be more logical if instead of IEnumerable, params could be used on IReadOnlyList
And, method return type inference!
@Dave Van den Eynde
Are you sure it doesn't solve it.
becomes
would more often become written using an extension method:
Or using the number 3 "Static type using statements" it might be written
Lets wait and see how all this composes.
Suraj Deshpande is right. I felt that the syntaxes presented here are expressed as unreadable statements and they are hard to maintain. Shorthands are supposed to be readable. It would be nice to write a bit more code in order to be maintainable.
#7 is cool and all, but it won't make my homebrew Maybe extension method obsolete. Right now I can do this:
Now that would be fine if it was obj?.Property instead, but I use it more often like this:
I don't see how this new operator would "fix" that use case.
I cannot stress enough how important what Keith Dahlby said is. I often had beautiful functional constructs that needed to use local variables just because of Try methods.
In other news, I would like to see 4 & 5 combined as well:
Have to agree with Patrick on this one.
I do like the groovy style null check syntax.
Algebraic data types, Higher kinded types, curried and partial function support like scala, scala style classes with primary constructors to reduce boilerplate code, type keyword for immuatable which is type checked, type aliases would be cool, enums as generic params as with integers like C++,
It's good to see C# evolving. Most of the possible changes are welcome, but I can't see any true radical changes on the horizon, which for the most part is a good thing. The last thing I would want is to have C# change into some horrible C++ like language, trying to squeeze every type of programming structure into the language. I've been using C# since 2004 and feel that it has reached a maturity that won't be helped by simply adding features for very little gain.
People wanting progress to a more advanced and robust language on the .NET platform should simply go to F#. I've been using F# now for 3 years and I could never go back to C# as my primary problem solving language. Here is the list the goodness that F# provides ...
The above features are what you need in a true 21st century programming language, and are unlikely to be incorporated into C# any time soon.
Given the massive attack vector it opens I'm okay with that.
{Turns on the news} "The human race has come together and we've landed on Mars & C# still doesn't have string interpolation"
My idea, a FormatStringAttribute to mark methods that take format strings and then to automate variable interpolation using names instead of positions.
Could become..
No more having to keep position and argument order in line.
I would love to see more focus on performance issues. Most of these things are frankly useless typically.
The only relevant things to me are:
I want to see:
I would also like to see the template support. Useful for Vectors that need to be either float based or doubled based.
Also things like CPU determined types like IntPtr but for ints and floats. floatx = "float on ARM32 or double on x86_64" etc... intx = "int on ARM32 or int64 on x86_64" etc...
Love the list. Will be pondering on this for some time. What about…
Given:
Perhaps:
or
I like #7 most of all.
But #1 and #9 seems like it'll just cause maintainability issues.
At first I saw no point in this syntax:
However, you need the x to exist so you can pass the property as an out or ref parameter, if that is the way you need to set it in the constructor, so I think it's great.
@Keith Hill - It's "kind of like" but it isn't, so I don't think you can use unchecked here. You could use a new keyword, but new syntax might be better.
I think I prefer this over ?., because I think it would be wrong to have code like this:
Note I started out using
?.and switched to just.in that expression. I can think of no valid reason to ever do that, but it seems like an easy thing to do by mistake. The?()syntax resolves that issue.My favourites are 4, 5 and 9. I'm wondering if they're gonna change the proposed syntax strongly... I really like this lambda style.
@Laksh - I live the idea of monadic null checking but I don't like the syntax. I wish we could do something like this:
This is kind of like the suppression of integer overflow checking.
I love 7, and actually, it's the only I'd like to see out of the list, no offence intended.
3 has been supported by VB.NET forever if I'm not wrong.
Would love to see extension properties, enum constraints for generics and a specification of the value type class for numbers, say, NumericValueType. Not to mention, SIMD.
Some of the changes are good. However i think these changes will make the code less human readable. We are not writing code just for computer to understand but it should also readable by other humans. Especially 7. Monadic null checking
I'm surprised at the number of people who think the syntax makes things harder to read or parse. Sure they look a little odd now but seeing a single line like:
Will mean you immediately identify this is a readonly property in the future. Right now, you have to go to definition to go see what x is defined as and if it has a readonly property.
The same is true of the safe null operator - you won't have to mentally parse several "if null" checks just to understand it wants a property via some optional objects.
I agree with you on primary constructors. They seem oddly limited whereas something like what you propose - public Point(set int x, set int y) could be used on any constructor.
I think I like 3 onwards; 1 and 2 are... kind of weird: as though they do make sense, but don't fit within the psychology of C# in some way. I think 1 is actively horrible... I can see what they're doing, but it appears to me that it'll make the code very hard to parse: it might make sense to the compiler, but I don't think it'll make a hell of a lot of sense to the user. And if you can do that in a constructor, can you do it in a method? Logic says you should be able to. What about if you do it in a loop in the constructor...? It's a bit too ambiguous.
@mike: These came from somebody on the C# design team. They are not my suggestions.
@Damien : you forgot to mention the 3rd option with params : you can totally ignore it and pass nothing at all.
I like the the Before and After examples; they make the changes very clear.
Talking about code noise reduction - I would like to see a simple 'is one of' operator for comparison - perhaps =[
Interesting, but I don't really see that much benefit to most of these. I agree with Scott Holodak, my biggest concern about these types of "enhancements" is that they tend to obfuscate the code, and when you are dealing with enterprise applications and their maintenance by experts and novices, I view most of these as an impediment to the end goal; I do, however like #3 and #6 and see some benefit to #7 providing the syntax could be made more readable for beginners.
What about having null checks built into ctors (mixed with auto private field creation) ?
public class SomeClass(notnull set OtherClass instance) { }
Wow #7 would be huge. I thought there wasn't much they could do with C# to entice me to feel like I needed to upgrade. This list makes me want C# 6 now.
I also wish for property fields. Where the variable has class lifetime but can only be accessed inside the property
this is going to be total mess if they implement all those syntaxes. especially in large teams where always one or two post graduates who have no clue what they are doing but 'love' writing cryptic mess.. And the devs who are responsible for pushing out the actual product will waste more time cleaning it.. Much more time than those 'tricks' will save in writing... #9 is only feature adding something to development process.
The constructor change is a massive improvement over previous versions of C#. Forcing the split between assignment and declaration seemed like a poor design choice. I imagine that fixing it will get rid of many null reference exceptions.
It is a shame we'll have to wait so long for C# to catch up with other languages like F# & Scala though!
F# is available today and already has:
If anyone reading this would like to learn more about F# (from a C# perspective) I can recommend these resources:
After writing and maintaining code for the past 20 years, anything that hides the meaning of code, even if it saves a couple key strokes, is just a bad idea. These are mostly no more valuable than fads and they reduce maintainability. If you want it to be maintainable, code should read like a story. KISS... the most basic and universal engineering principle.
Why not use the most intuitive syntax for readonly auto properties:
wow! c# slowly moves to scala... by the way, your post is clear and interesting! thanks!
Only number 7 has any chance of making it to C# 6.0. The design team is very, very conservative when it comes to adding features, and most of these are just not worth the effort, especially considering they are rewriting the compiler.
To predict new C# features, you have to consider what compiler as a service enables. The new compiler will enable you to peek inside the AST, so I suspect more dynamics wrt compiling/inspecting code, not new language features.
For 6: Is evaluation deferred until evaluated if you pass a single IEnumerable instead of a params?
params (certainly for arrays, I'd expect for enumerable also) affects the call site, not the method itself - once you're inside the code of the method, params doesn't affect anything - you just have an array or an enumerable. As such, if someone has called your method and passed an array/enumerable directly, you just receive whatever they've passed you - the params "machinery" is not involved at all.
As such, I'd strongly suspect that you get deferred evaluation.
(3) could mean that instead of the
could be expressed more like I can do in Delphi now:
aka
It would be the nice comeback of the one line/at a glance auxiliares.
I expected MS to start shifting more towards F#, but it's nice to see C# is still getting plenty of attention. Those are very nice features. I especially like method expressions and monadic null checking. Features 1-4 I don't like so much, because they seem to me like they will bring confusion into code. I think those are big updates, maybe too big for a mature language such as C#, considering that they don't bring so much value to the table.
Nice post! I also thought about writing an opinionated follow up whilst walking to work this morning ;-)
I'll put up my follow up post soon, I think my thoughts are largely similar to yours though.
Saat nambar ta Ekhani chai (#7 want right now) !
"Monadic null checking"
Some of these are nice, love 7,9 but would love to see some features that change what's possible rather than cleaning syntax. I would love to be able to use Lambda Expressions as constructor parameters for Attributes
Yes please to #6, #7 and #9. Not really excited about any of the other ones. I'd be concerned that #1-#5 would impact readability/maintainability, particularly in teams where you have experts and beginners trying to peacefully coexist in the same code base.
@Damien: thank you for explanation. I don't really know how "params" is implemented under the hood (I may guess how it works, but not sure), but let's take a start from the idea of "unrolling" of what the "params" is designed for: generally speaking it's designed just to simplify passing more same-typed arguments to variadic methods reducing the number of overloads. So basically all arguments must be evaluated before they are passed to a method in eager manner just like if they were "regular" arguments. I think that eager evaluation for method arguments is a must for CLR design, and if lazy evaluation for sequences is necessary, the IEnumerable must be used in the method explicitly, because array (and "params") item dereferrencing operator assumes that the whole sequence is known, and kept, for non-abstract instance, in memory -- IEnumerable does not have size per se by design.
@james: While the scoping there would be great for the Try pattern it would render this function useless for DirectX programming where there are a lot of out parameters simply to avoid copying back and forth via the stack.
@Lyubomyr: With (params int someValues) you have two options - comma separated parameters and an array. Sometimes we have an array and so we have to pass that. Other times we have an IEnumerable and have to force evaluation.
With the new syntax I'd imagine people start switching to the IEnumerable syntax so that you can either comma separate the parameters or pass any enumerable (including array) to be evaluated as required. It should replace the older syntax as time goes on.
(1) "primary constructors" syntax is scary. I don't believe that it can be accepted. Ever.
(3) is good borrowing the idea of static imports from Java. The code can be much and much cleaner, that's true. However, I'd like to import particular classes, and other first class members. The "using" keyword is uncontrollable when simply importing whole namespaces. Extension methods introducing is even more uncontrollable and unpredictable.
(6) Couldn't understand it. Isn't passing IEnumerable enough?
(9) Unnecessary and, according to James Hart, causes issues.
(Wrapping Up) I do believe that introducing meta-programming can obtain more efficiency and enhancements at compile time. The given example is about a Decorator design pattern implementation, and a meta-programming template can easily cover this case without enhancing the language itself -- you'd enhance the language yourself. Even a simple "foreach" statement could be expressed using a template. But it's a different story.
The improvement of inline out variable declaration might be more subtle than just eliminating the need for a prior declaration - it permits the scope of the variable to be reduced to where it belongs:
Before:
After:
Liviu I have had something even more robust imo for a long time... at maybe.codeplex.com you can do obj.Maybe(x=>x.Prop1.Prop2).
1, 4. 5 for extra readability.
pattern matching would be great
Looks interesting, but some syntaxs are confusing to me.
Safe navigation is a killer, now i use following to simulate it:
Safe is R Safe(Func propaccess)...
What bothers me in these examples, is that the new features are just some cosmetic stuff, easy to implement by an intern, when having a good parser like Roslyn...
Why not syntactic macros, or again: string interpolation like many new and old languages have implemented for ages? Why is C# so conservative?
I can't wait for #7. I'd actually be willing to kill for it right now.
This is NOT monadic null checking Monadic null checking would be using an Option or Maybe class and using LINQ extension method (specifically SelectMany) for stacking checks such as
Make sense?
Imitation being the sincerest form or flattery; F# should be very flattered! Still, looks a nice set of improvements.
For (1) Primary Constructors, I prefer a syntax which allows me to prefix the private instance variables with an underscore ( _x and _y ). This naming convention makes the code more readable, since one can easily distinguish between private instance variables ( _x and _y ) and method local variables ( say m and n ).
I hope you will be also able to write:
It is one of places there you have to declare type and cannot use
var.Yeah! Let's add more keywords doing nothing new in new ways and call that a new version !!
Seriously, I feel bad for CSharpers. It is really time they jump on the Fsharp wagon which is all that's left to be cool on the CLR.
I feel like I've been waiting for Monadic null checking (7) all my life. Primary Constructors (1) is a fantastic idea but I am not a fan of the given syntax. I like your rewrite. My first thought was to use the 'this' keyword, but 'set' allows it to be intuitive in static constructors as well. I'm not sure I like the idea of auto-creating private fields/properties if they don't exist. That seems like it could easily cause confusion with anyone not familiar with the language feature.
I would love to see more hardcore features like : string interpolation dynamic enhancements and not least: Lambda Expressions to support statements...
What's interesting about inline out declarations this is that a series of statements is now replaced by an expression, so you could do something like this:
Thanks Jesper that makes a lot more sense, I was sure I was wrong. I will update the post.
4/5: "Expression" in this context does not mean involving expression tree types at all, just expressions that are not standalone statements in brackets. Like how "1 + 2" in "() => 1 +2;" is not "() => { return 1+ 2; }".
So:
as a shorter way of writing
It's going to be interesting how these play out. I'm not sure I like the syntax for #1 or #2