Probable C# 6.0 features illustrated

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

81 responses  

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

    Blake NiemyjskiDecember 9th, 2013
  2. 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)); } }
    Jesper – December 9th, 2013
  3. Thanks Jesper that makes a lot more sense, I was sure I was wrong. I will update the post.

    [)amien

    Damien GuardDecember 9th, 2013
  4. 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 DahlbyDecember 9th, 2013
  5. I would love to see more hardcore features like :
    string interpolation
    dynamic enhancements
    and not least: Lambda Expressions to support statements…

    Liviu – December 9th, 2013
  6. 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 JeppsonDecember 9th, 2013
  7. 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 – December 9th, 2013
  8. 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 – December 9th, 2013
  9. 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 ).

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

    David – December 9th, 2013
  11. 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 – December 9th, 2013
  12. I can’t wait for #7. I’d actually be willing to kill for it right now.

    Enrique – December 9th, 2013
  13. 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?

    liviu – December 10th, 2013
  14. Looks interesting, but some syntaxs are confusing to me.

    Suraj DeshpandeDecember 10th, 2013
  15. 1, 4. 5 for extra readability.

    pattern matching would be great

    Giles – December 10th, 2013
  16. 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).

    Brandon DDecember 10th, 2013
  17. 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

    After:

    if (int.TryParse(whatever, out int i)) { /* do stuff with a valid i */ }
    // now i is out of scope
    James Hart – December 10th, 2013
  18. (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 – December 10th, 2013
  19. @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.

    [)amien

    Damien GuardDecember 10th, 2013
  20. @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.

    [)amien

    Damien GuardDecember 10th, 2013
  21. @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 – December 10th, 2013
  22. 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 HolodakDecember 10th, 2013
  23. 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 RoseDecember 10th, 2013
  24. Saat nambar ta Ekhani chai (#7 want right now) !

    “Monadic null checking”
    var bestValue = points?.FirstOrDefault()?.X ?? -1;

    Debiprasad Ghosh – December 10th, 2013
  25. 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 RalphDecember 11th, 2013
  26. 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.

    NikolaDecember 11th, 2013
  27. (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.

    Peter Adam – December 11th, 2013
  28. 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 – December 11th, 2013
  29. 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 – December 11th, 2013
  30. wow! c# slowly moves to scala… by the way, your post is clear and interesting! thanks!

    alejandro – December 11th, 2013
  31. Why not use the most intuitive syntax for readonly auto properties:

    public int X { get; readonly set; }

    ?

    Joakim – December 11th, 2013
  32. 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.

    MikeDecember 11th, 2013
  33. 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:
    - http://skillsmatter.com/podcast/home/f-eye-for-the-c-sharp-guy
    - http://www.slideshare.net/ptrelford/f-sharp-eye-for-the-csharp-guy-ddd-north-2013
    - http://fsharp.org/

    Zach BrayDecember 11th, 2013
  34. 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 – December 11th, 2013
  35. 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 TuckerDecember 11th, 2013
  36. What about having null checks built into ctors (mixed with auto private field creation) ?

    public class SomeClass(notnull set OtherClass instance) { }

    Ricardo RodriguesDecember 11th, 2013
  37. 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 – December 11th, 2013
  38. 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 BlanchetDecember 11th, 2013
  39. I like the the Before and After examples; they make the changes very clear.

    Alan8 – December 11th, 2013
  40. @Damien : you forgot to mention the 3rd option with params : you can totally ignore it and pass nothing at all.

    XXXo – December 11th, 2013
  41. @mike: These *came* from somebody on the C# design team. They are not my suggestions.

    [)amien

    Damien GuardDecember 11th, 2013
  42. 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 SuttonDecember 11th, 2013
  43. 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 HillDecember 11th, 2013
  44. 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.

    [)amien

    Damien GuardDecember 11th, 2013
  45. 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 – December 11th, 2013
  46. 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.

    PeteDecember 11th, 2013
  47. 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 – December 11th, 2013
  48. @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 HillDecember 11th, 2013
  49. 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.

    domin8kDecember 11th, 2013
  50. @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 – December 11th, 2013
  51. 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 – December 11th, 2013
  52. 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();
    Rick – December 11th, 2013
  53. 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…

    AndrewDecember 11th, 2013
  54. 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 – December 12th, 2013
  55. {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 – December 12th, 2013
  56. Given the massive attack vector it opens I’m okay with that.

    Damien GuardDecember 12th, 2013
  57. 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 – December 13th, 2013
  58. 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++,

    BlairDecember 16th, 2013
  59. 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 – December 18th, 2013
  60. #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.

    Dave Van den Eynde – January 10th, 2014
  61. 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 – January 11th, 2014
  62. @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.

    David Taylor – February 6th, 2014
  63. #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 – February 7th, 2014
  64. 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 – February 7th, 2014
  65. Inspired from functional programming? Most ideas sounds similar to fsharp.

    Vallarasu – February 7th, 2014
  66. 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 – February 9th, 2014
  67. 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 – February 11th, 2014
  68. 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 BowersFebruary 15th, 2014
  69. 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 – March 1st, 2014
  70. 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

    Alan Bates – March 11th, 2014
  71. 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; }
    }
    NNMarch 15th, 2014
  72. 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 VeldhuizenMarch 18th, 2014
  73. 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; }
    JendaMarch 21st, 2014
  74. To John Bergman:

    public static bool In(this T obj, params T[] list) {
      return list.Contains(obj);
    }
    ...
    if (x.In(3,6,8,12)) { ...
    JendaMarch 21st, 2014
  75. 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 – March 29th, 2014
  76. pingback

    […] Having been away on holiday recently, I’ve been doing a bit of catching up on the backlog of RSS-based reading that a week out of the office has generated. And one item stuck out at me as particularly interesting: some of the new features being discussed for the v6 release of the C# compiler. I came across a couple of articles discussing presentations given by Mads Torgersen (the C# Programme Manager) at the end of last year discussing some interesting feature proposals […]

    Bonus chatter: My favourite proposed feature for C# v6 | Jeremy DavisMarch 29th, 2014
  77. Values. Like ‘var’ but cannot be changed.

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

    Currently it’s impossible to force this.

    Wouter – April 10th, 2014
  78. 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 UlsbergApril 11th, 2014
  79. pingback

    […] Probable C# 6.0 features illustrated […]

    Episode 10 – C# 6 and Roslyn – Pour Some Sugar On MeMay 4th, 2014
  80. 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 – May 30th, 2014
  81. 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 – June 17th, 2014