Probable C# 6.0 features illustrated

📅 09/12/2013
📝 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 =&gt; myList {
  private IList myList;

  public Add(object item) {
    // Do something first
    myList.Add(item);
  }
}

[)amien

79 responses to Probable C# 6.0 features illustrated

Information is only used to show your comment. See my Privacy Policy.
Pavel17/06/2014
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.
int X=>x*x; int X {get {x*x;}}; var x=(var y=rand(10);y*y);
And it increases the readability of the program…
public double Distance => Math.Sqrt((X * X) + (Y * Y));
At a first glance it might be confused with the delegate
Indexed member initializer:
new JObject { $x = 3, $y = 7
and indexed member access
c.$name = c.$first + " " + c.$last;
It generally looks like a failed attempt to realize the potential of DLR. The next step will probably be the following:
var n = "name"; c.$(n) = c.$("first") + " " + c.$last;
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:
string s = nameof(Console.Write);
Although perhaps will finally something useful. If you do not think that there are better implementation..
Matthijs Wessels30/05/2014
Looks great. For #1, I like the way TypeScript has done this:
public class Point { public Point(private int x, public int y, int z) // other initialisation using z. }
Asbjørn Ulsberg11/04/2014
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 readonly keyword?
public readonly int X { get; }
Wouter10/04/2014
Values. Like var but cannot be changed.
val five = 5; five = 6; // Causes error
Currently it’s impossible to force this.
Leon29/03/2014
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 MyClass and not MyClass
var x = new MyClass(1, "X"); var y = new MyClass("x", 1);
x and y are not compatible with each other.
I guess 8 is OK if the programmers use it like this:
MyClass x = new MyClass(1, "X"); MyClass y = new MyClass("x", 1);
Jenda21/03/2014
To John Bergman:
public static bool In(this T obj, params T[] list) { return list.Contains(obj); } .. if (x.In(3,6,8,12)) { .. }
Jenda21/03/2014
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
public static int Timeout { get; set; } = 100;
in place of
private static int _timeout = 100; public static int Timeout { get { return _timeout; } set { _timeout = value;
than … waitasecond … what does that example actually mean?!? Is the
public int X { get; } = x;
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
public int X { get; readonly set;
Marcel Veldhuizen18/03/2014
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
public readonly int X { get;
NN15/03/2014
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.
class A { public Prop : int { get; } // Public property and hidden private field public this() { Prop = 1; // Initialization in constructor writes to the hidden field } }
And this is how simple immutable class with constructors and properties looks like:
[Record] class Data { public Name : string { get; } public MiddleName : string { get; } public Address : string { get; } }
Alan Bates11/03/2014
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
foreach(var entity in entities)
or
foreach(Entity entity in entities)
just simply
foreach(entity in entities)
...while still allowing the explicit case
Joz01/03/2014
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.
Jason Bowers15/02/2014
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.
Carlos Beppler11/02/2014
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:
public string MyProp { string myprop = string.Empty; get { return myprop; } set { if (string.IsNullOrWhiteSpace(value)) throw new ArgumentNullException("value"); myprop = value; } }
someone09/02/2014
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.
Vallarasu07/02/2014
Inspired from functional programming? Most ideas sounds similar to fsharp.
João Vitor P. Moraes07/02/2014
Why is that x introduced on read only properties?
public int X { get; } = x;
Why not simply
public int X { get;
And the setter acts like a read-only attribute? The proposed syntax allows for things like
public int X { get; } = y;
and in the constructor you would have
y = 5
which would only bring confusion
X = 5
is cleaner, simpler, and avoids confusion.
Kralizek07/02/2014
#6 would be more logical if instead of IEnumerable, params could be used on IReadOnlyList
And, method return type inference!
public var GetValue() { return 1; }
David Taylor06/02/2014
@Dave Van den Eynde
Are you sure it doesn’t solve it.
obj.Maybe(obj => obj.Property);
becomes
obj?.Property
obj.Maybe(ProjectionFunc);
would more often become written using an extension method:
obj?.ProjectionFunc()
Or using the number 3 “Static type using statements” it might be written
ProjectionFunc(obj?)
Lets wait and see how all this composes.
Junior11/01/2014
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.
Dave Van den Eynde10/01/2014
#7 is cool and all, but it won’t make my homebrew Maybe extension method obsolete. Right now I can do this:
obj.Maybe(obj =? obj.Property);
Now that would be fine if it was obj?.Property instead, but I use it more often like this:
obj.Maybe(ProjectionFunc);
I don’t see how this new operator would “fix” that use case.
tec-goblin18/12/2013
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:
public ISet IdSet { get => new HashSet(ids.Split(",")); set { ids = value == null ? null : string.join(value, ","); } }
Blair16/12/2013
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++,
Patrick13/12/2013
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 …
Immutability by default
Option types (eliminates null exceptions)
Algebraic Data Types
Units of Measure
Pattern Matching
Computation Expressions
Type Providers
Real nested functions
Proper record types
Non-nullable reference types
Value based semantics
Hindley–Milner type inference
Curried functions and partial function application
Function in-lining
Succinct tuple syntax and manipulation
Object Expressions (create interface implementations on-the-fly without a concrete class implementation)
Elimination of uninitialized variables
Statically resolved type parameters (aka type-safe static duck typing)
Type synonyms/aliases
Type-safe string formatting
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.
Damien Guard12/12/2013
Given the massive attack vector it opens I’m okay with that.
Eric Williams12/12/2013
{Turns on the news} “The human race has come together and we’ve landed on Mars & C# still doesn’t have string interpolation”
Tom R12/12/2013
My idea, a FormatStringAttribute to mark methods that take format strings and then to automate variable interpolation using names instead of positions.
Console.WriteLine("A = {0} B = {1} C = {2}", variableA, b.Property, _fieldC);
Could become..
Console.WriteLine("A = {variableA} B = {b.Property} C = {_fieldC}");
No more having to keep position and argument order in line.
Andrew11/12/2013
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:
Better property backing syntax
"Inline declarations for out params"
"Params for enumerables"
"Static type using statements;"
I want to see:
SIMD support for x86_64 and NEON
Auto vectorization to get closer speeds to that of C++
Allow pointer types without the need for an unsafe block(as a project setting)(Or add a compiler attribute that fixes structs in memory)
Make the base runtime OPEN SOURCE for crying out loud(like .NET Micro). This doesn't mean your frameworks need to be Open
More focus on RUNTIME performance, not just cold boot. Cold boot is irreverent to games, runtime performance if far more important
More focus on performance in the JIT period. As C# is far more productive then C++ for rapid game dev
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…
Rick11/12/2013
Love the list. Will be pondering on this for some time. What about…
Given:
List myList;
Perhaps:
myList? new List {"value"}; myList? throw new MyListNullException();
or
myList?? new List {"value"}; myList?? throw new MyListNullException();
Corrie11/12/2013
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:
public int X { get; } = x;
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.
wekempf11/12/2013
@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.
var bestValue = ?(points.FirstOrDefault().X) ?? -1;
I think I prefer this over ?., because I think it would be wrong to have code like this:
var bestValue = points?.FirstOrDefault().X ?? -1;
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.
domin8k11/12/2013
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.
Keith Hill11/12/2013
@Laksh — I live the idea of monadic null checking but I don’t like the syntax. I wish we could do something like this:
var bestValue = unchecked(points.FirstOrDefault().X) ?? -1;
This is kind of like the suppression of integer overflow checking.
HB11/12/2013
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.
Pete11/12/2013
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.
Laksh11/12/2013
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
Damien Guard11/12/2013
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:
public int X { get; } = x;
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.
Keith Hill11/12/2013
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.
Dan Sutton11/12/2013
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.
Damien Guard11/12/2013
@mike: These came from somebody on the C# design team. They are not my suggestions.
XXXo11/12/2013
@Damien : you forgot to mention the 3rd option with params : you can totally ignore it and pass nothing at all.
Alan811/12/2013
I like the the Before and After examples; they make the changes very clear.
Michael Blanchet11/12/2013
Talking about code noise reduction — I would like to see a simple ‘is one of’ operator for comparison — perhaps =[
if ( x =[ 5,6,7 ) ... or if ( str =[ "A","B","C" ) ...
John Bergman11/12/2013
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.
Ricardo Rodrigues11/12/2013
What about having null checks built into ctors (mixed with auto private field creation) ?
public class SomeClass(notnull set OtherClass instance) { }
Tom Tucker11/12/2013
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
public string MyProp { string myprop; get { return myprop; } set { myprop = value; } }
Bobb11/12/2013
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.
Zach Bray11/12/2013
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:
More concise constructor syntax than C#
Record types & record expressions (not available in C#)
More concise property syntax than C#
Language support for tuple types
Non-nullable reference types (no need for the ugly '?' operator like C#)
Hindley-Milner type inference (far more versatile than C#'s var and proposed constructor inference)
If anyone reading this would like to learn more about F# (from a C# perspective) I can recommend these resources:
https://skillsmatter.com/podcast/home/f-eye-for-the-c-sharp-guy
https://www.slideshare.net/ptrelford/f-sharp-eye-for-the-CSharp-guy-ddd-north-2013
https://fsharp.org/
Mike11/12/2013
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.
Joakim11/12/2013
Why not use the most intuitive syntax for readonly auto properties:
public int X { get; readonly set; }
alejandro11/12/2013
wow! c# slowly moves to scala… by the way, your post is clear and interesting! thanks!
Mike11/12/2013
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.
Damien11/12/2013
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.
Peter Adam11/12/2013
(3) could mean that instead of the
MessageBox.Show("Message","Caption",MessageBoxButtons.OK,MessageBoxIcon.Question,MessageBoxDefaultButton.Button1)
could be expressed more like I can do in Delphi now:
Application.ShowMessage('Message','Caption',MB_OK+MB_ICONQUESTION+MB_DEFBUTTON1)
aka
MessageBox.Show("Message","Caption",OK,Question,Button1)
It would be the nice comeback of the one line/at a glance auxiliares.
Nikola11/12/2013
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.
Adam Ralph11/12/2013
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.
Debiprasad Ghosh10/12/2013
Saat nambar ta Ekhani chai (#7 want right now) !
“Monadic null checking”
var bestValue = points?.FirstOrDefault()?.X ?? -1;
Spencer Rose10/12/2013
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
Scott Holodak10/12/2013
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.
Lyubomyr Shaydariv10/12/2013
@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.
Damien Guard10/12/2013
@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.
Damien Guard10/12/2013
@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.
Lyubomyr Shaydariv10/12/2013
(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.
James Hart10/12/2013
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:
int i; if (int.TryParse(whatever, out i)) { /* do stuff with a valid i */ } // now i still exists but is in an 'unspecified' state</pre></code>
After:
if (int.TryParse(whatever, out int i)) { /* do stuff with a valid i */ } // now i is out of scope</pre></code>
Brandon D10/12/2013
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).
Giles10/12/2013
1, 4. 5 for extra readability.
pattern matching would be great
Suraj Deshpande10/12/2013
Looks interesting, but some syntaxs are confusing to me.
liviu10/12/2013
Safe navigation is a killer, now i use following to simulate it:
obj.Safe(x=>x.Prop1).Safe(y=>y.Prop2)
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?
Enrique09/12/2013
I can’t wait for #7. I’d actually be willing to kill for it right now.
vincent09/12/2013
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
var opt = from o1 in maybeNull from o2 in o1 ///which also might be null select new Test() { a = 01.Text, b = o2.Text };
Make sense?
David09/12/2013
Imitation being the sincerest form or flattery; F# should be very flattered! Still, looks a nice set of improvements.
Channs09/12/2013
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 ).
Boris Letocha09/12/2013
I hope you will be also able to write:
dict.TryGet("123", out var x)
It is one of places there you have to declare type and cannot use var.
Nicolas09/12/2013
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.
Josh Jeppson09/12/2013
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.
Liviu09/12/2013
I would love to see more hardcore features like : string interpolation dynamic enhancements and not least: Lambda Expressions to support statements…
Keith Dahlby09/12/2013
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:
s => int.TryParse(s, out int x) ? x : default(int?);
Damien Guard09/12/2013
Thanks Jesper that makes a lot more sense, I was sure I was wrong. I will update the post.
Jesper09/12/2013
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:
public double Distance => Sqrt((X * X) + (Y * Y));
as a shorter way of writing
public double Distance { get { return Sqrt((X * X) + (Y * Y)); } }
Blake Niemyjski09/12/2013
It’s going to be interesting how these play out. I’m not sure I like the syntax for #1 or #2

Probable C# 6.0 features illustrated

1. Primary Constructors

Before

After

Thoughts

2. Readonly auto properties

Before

After

Thoughts

3. Static type using statements;

Before

After

Thoughts

4. Property Expressions

Before

After

Thoughts

5. Method Expressions

Before

After

Thoughts

6. Params for enumerables

Before

After

Thoughts

7. Monadic null checking

Before

After

Thoughts

8. Constructor type parameter inference

Before

After

Thoughts

9. Inline declarations for out params

Before

After

Thoughts

Wrapping up

79 responses to Probable C# 6.0 features illustrated

Software Engineering

Typography

Articles by Subject

Quick Picks