Probable C# 6.0 features illustrated

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.


public class Point {
  private int x, y;

  public Point(int x, int y)
    this.x = x;
    this.y = y;


public class Point(int x, int y) {
  private int x, y;


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


private readonly int x;
public int X { get { return x; } }


public int X { get; } = x;


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


public double A { get { return Math.Sqrt(Math.Round(5.142)); } }


using System.Math;

public double A { get { return Sqrt(Round(5.142)); } }


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


public double Distance {
  get { return Math.Sqrt((X * X) + (Y * Y)); }


public double Distance => Math.Sqrt((X * X) + (Y * Y));


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


public Point Move(int dx, int dy) {
  return new Point(X + dx1, Y + dy1);


public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);


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.


public void Do(params int[] values) { ... }


public void Do(params IEnumerable<Point> points) { ... }


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


if (points != null) {
  var next = points.FirstOrDefault();
  if (next != null && next.X != null) return next.X;
return -1;


var bestValue = points?.FirstOrDefault()?.X ?? -1;


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.


var x = MyClass.Create(1, "X");

public MyClass<T1, T2> Create<T1, T2>(T1 a, T2 b) {
    return new MyClass<T1, T2>(a, b);


var x = new MyClass(1, "X");


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


int x;
int.TryParse("123", out x);


int.TryParse("123", out int x);


  • 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


79 responses

  1. Avatar for Blake Niemyjski

    It's going to be interesting how these play out. I'm not sure I like the syntax for #1 or #2

    Blake Niemyjski 9 December 2013
  2. Avatar for Jesper

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


    public double Distance => Sqrt((X * X) + (Y * Y));

    as a shorter way of writing

    public double Distance { get { return Sqrt((X * X) + (Y * Y)); } }
    Jesper 9 December 2013
  3. Avatar for Damien Guard

    Thanks Jesper that makes a lot more sense, I was sure I was wrong. I will update the post.

    Damien Guard 9 December 2013
  4. Avatar for Keith Dahlby

    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?);
    Keith Dahlby 9 December 2013
  5. Avatar for Liviu

    I would love to see more hardcore features like : string interpolation dynamic enhancements and not least: Lambda Expressions to support statements...

    Liviu 9 December 2013
  6. Avatar for Josh Jeppson

    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.

    Josh Jeppson 9 December 2013
  7. Avatar for Nicolas

    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.

    Nicolas 9 December 2013
  8. Avatar for Boris Letocha

    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.

    Boris Letocha 9 December 2013
  9. Avatar for Channs

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

    Channs 9 December 2013
  10. Avatar for David

    Imitation being the sincerest form or flattery; F# should be very flattered! Still, looks a nice set of improvements.

    David 9 December 2013
  11. Avatar for vincent

    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?

    vincent 9 December 2013
  12. Avatar for Enrique

    I can't wait for #7. I'd actually be willing to kill for it right now.

    Enrique 9 December 2013
  13. Avatar for liviu

    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?

    liviu 10 December 2013
  14. Avatar for Suraj Deshpande

    Looks interesting, but some syntaxs are confusing to me.

    Suraj Deshpande 10 December 2013
  15. Avatar for Giles

    1, 4. 5 for extra readability.

    pattern matching would be great

    Giles 10 December 2013
  16. Avatar for Brandon D

    Liviu I have had something even more robust imo for a long time... at you can do obj.Maybe(x=>x.Prop1.Prop2).

    Brandon D 10 December 2013
  17. Avatar for James Hart

    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:


    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>


    if (int.TryParse(whatever, out int i)) { /* do stuff with a valid i */ }
    // now i is out of scope</pre></code>
    James Hart 10 December 2013
  18. Avatar for Lyubomyr Shaydariv

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

    Lyubomyr Shaydariv 10 December 2013
  19. Avatar for Damien Guard

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

    Damien Guard 10 December 2013
  20. Avatar for Damien Guard

    @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 Guard 10 December 2013
  21. Avatar for Lyubomyr Shaydariv

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

    Lyubomyr Shaydariv 10 December 2013
  22. Avatar for Scott Holodak

    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.

    Scott Holodak 10 December 2013
  23. Avatar for Spencer Rose

    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

    Spencer Rose 10 December 2013
  24. Avatar for Debiprasad Ghosh

    Saat nambar ta Ekhani chai (#7 want right now) !

    "Monadic null checking"

    var bestValue = points?.FirstOrDefault()?.X ?? -1;
    Debiprasad Ghosh 10 December 2013
  25. Avatar for Adam Ralph

    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.

    Adam Ralph 11 December 2013
  26. Avatar for Nikola

    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.

    Nikola 11 December 2013
  27. Avatar for Peter Adam

    (3) could mean that instead of the


    could be expressed more like I can do in Delphi now:




    It would be the nice comeback of the one line/at a glance auxiliares.

    Peter Adam 11 December 2013
  28. Avatar for Damien

    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.

    Damien 11 December 2013
  29. Avatar for Mike

    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.

    Mike 11 December 2013
  30. Avatar for alejandro

    wow! c# slowly moves to scala... by the way, your post is clear and interesting! thanks!

    alejandro 11 December 2013
  31. Avatar for Joakim

    Why not use the most intuitive syntax for readonly auto properties:

    public int X { get; readonly set; }
    Joakim 11 December 2013
  32. Avatar for Mike

    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.

    Mike 11 December 2013
  33. Avatar for Zach Bray

    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:

    Zach Bray 11 December 2013
  34. Avatar for Bobb

    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.

    Bobb 11 December 2013
  35. Avatar for Tom Tucker

    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; }
    Tom Tucker 11 December 2013
  36. Avatar for Ricardo Rodrigues

    What about having null checks built into ctors (mixed with auto private field creation) ?

    public class SomeClass(notnull set OtherClass instance) { }

    Ricardo Rodrigues 11 December 2013
  37. Avatar for John Bergman

    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.

    John Bergman 11 December 2013
  38. Avatar for Michael Blanchet

    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" ) ...
    Michael Blanchet 11 December 2013
  39. Avatar for Alan8

    I like the the Before and After examples; they make the changes very clear.

    Alan8 11 December 2013
  40. Avatar for XXXo

    @Damien : you forgot to mention the 3rd option with params : you can totally ignore it and pass nothing at all.

    XXXo 11 December 2013
  41. Avatar for Damien Guard

    @mike: These came from somebody on the C# design team. They are not my suggestions.

    Damien Guard 11 December 2013
  42. Avatar for Dan Sutton

    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.

    Dan Sutton 11 December 2013
  43. Avatar for Keith Hill

    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.

    Keith Hill 11 December 2013
  44. Avatar for Damien Guard

    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.

    Damien Guard 11 December 2013
  45. Avatar for Laksh

    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

    Laksh 11 December 2013
  46. Avatar for Pete

    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.

    Pete 11 December 2013
  47. Avatar for HB

    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.

    HB 11 December 2013
  48. Avatar for Keith Hill

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

    Keith Hill 11 December 2013
  49. Avatar for domin8k

    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.

    domin8k 11 December 2013
  50. Avatar for wekempf

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

    wekempf 11 December 2013
  51. Avatar for Corrie

    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.

    Corrie 11 December 2013
  52. Avatar for Rick

    Love the list. Will be pondering on this for some time. What about…


    List myList;


    myList? new List {"value"};
    myList? throw new MyListNullException();


    myList?? new List {"value"};
    myList?? throw new MyListNullException();
    Rick 11 December 2013
  53. Avatar for Andrew

    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:

    1. Better property backing syntax
    2. "Inline declarations for out params"
    3. "Params for enumerables"
    4. "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...

    Andrew 11 December 2013
  54. Avatar for Tom R

    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.

    Tom R 12 December 2013
  55. Avatar for Eric Williams

    {Turns on the news} "The human race has come together and we've landed on Mars & C# still doesn't have string interpolation"

    Eric Williams 12 December 2013
  56. Avatar for Damien Guard

    Given the massive attack vector it opens I'm okay with that.

    Damien Guard 12 December 2013
  57. Avatar for Patrick

    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.

    Patrick 13 December 2013
  58. Avatar for Blair

    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++,

    Blair 16 December 2013
  59. Avatar for tec-goblin

    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, ","); }
    tec-goblin 18 December 2013
  60. Avatar for Dave Van den Eynde

    #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:


    I don't see how this new operator would "fix" that use case.

    Dave Van den Eynde 10 January 2014
  61. Avatar for Junior

    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.

    Junior 11 January 2014
  62. Avatar for David Taylor

    @Dave Van den Eynde

    Are you sure it doesn't solve it.

    obj.Maybe(obj => obj.Property);



    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.

    David Taylor 6 February 2014
  63. Avatar for Kralizek

    #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;
    Kralizek 7 February 2014
  64. Avatar for João Vitor P. Moraes

    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.

    João Vitor P. Moraes 7 February 2014
  65. Avatar for Vallarasu

    Inspired from functional programming? Most ideas sounds similar to fsharp.

    Vallarasu 7 February 2014
  66. Avatar for someone

    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.

    someone 9 February 2014
  67. Avatar for Carlos Beppler

    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;
    Carlos Beppler 11 February 2014
  68. Avatar for Jason Bowers

    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.

    Jason Bowers 15 February 2014
  69. Avatar for Joz

    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.

    Joz 1 March 2014
  70. Avatar for Alan Bates

    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)


    foreach(Entity entity in entities)

    just simply

    foreach(entity in entities)

    ...while still allowing the explicit case

    Alan Bates 11 March 2014
  71. Avatar for NN

    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:

    class Data
        public Name : string { get; }
        public MiddleName : string { get; }
        public Address : string { get; }
    NN 15 March 2014
  72. Avatar for Marcel Veldhuizen

    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;
    Marcel Veldhuizen 18 March 2014
  73. Avatar for Jenda

    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;
    Jenda 21 March 2014
  74. Avatar for Jenda

    To John Bergman:

    public static bool In(this T obj, params T[] list) {
        return list.Contains(obj);
    if (x.In(3,6,8,12)) { ..
    Jenda 21 March 2014
  75. Avatar for Leon

    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);
    Leon 29 March 2014
  76. Avatar for Wouter

    Values. Like var but cannot be changed.

    val five = 5;
    five = 6; // Causes error

    Currently it's impossible to force this.

    Wouter 10 April 2014
  77. Avatar for Asbjørn Ulsberg

    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; }

    Asbjørn Ulsberg 11 April 2014
  78. Avatar for Matthijs Wessels

    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.
    Matthijs Wessels 30 May 2014
  79. Avatar for Pavel

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

    Pavel 17 June 2014