C# 6: First reactions

http://msmvps.com/blogs/jon_skeet/archive/2014/04/04/c-6-first-reactions.aspx

by yulaow • 12 years ago

117 65 12 years ago

msmvps.com

AndrewDucker2• 12 years ago

Is there a list anywhere of all the new functionality?

sz4kerto• 12 years ago

http://damieng.com/blog/2013/12/09/probable-c-6-0-features-i...

... so, in short, nothing definite yet, but the list above should be more or less accurate.

_random_• 12 years ago

Yes, of course:

https://roslyn.codeplex.com/wikipage?title=Language%20Featur...

nbevans• 12 years ago

How tragic it is that VB gets type cases, guard cases and exception filters well before C#.

I guess that's why F# is starting to hit the prime time.

MichaelAza• 12 years ago

Some of these seem undocumented anywhere that I could find.

I posted an SO question about some of them, if anyone has any input on the matter: http://stackoverflow.com/questions/22881465/what-do-these-ne...

icambron• 12 years ago

Lot of good stuff in there. I don't use C# day-to-day anymore, but I always wanted string interpolation.

bruceboughton3• 12 years ago

I'm not sure of this direction. It looks like a rather large syntax explosion to cover a bunch of corner cases. C# doesn't want to become Perl. That's my initial gut feeling but perhaps that will change.

Does anyone know what the dollar syntax is? Similarly, the new dictionary initialiser syntax? Fisnlly, what is private protected?

Edit: these are from https://roslyn.codeplex.com/wikipage?title=Language%20Featur...

chrisoverzero• 12 years ago

Given C# Dictionary access as Dict["key"], the equivalent using dollar syntax is Dict.$key.

C# Dictionary initialization is currently something like this:

    var d = new Dictionary<string, string>
    {
      { "key", "value" },
      { "but this one", "has spaces" }
    }

The new syntaxes appear to be these:

    var d = new Dictionary<string, string>
    {
      $key = "value",
      ["but this one"] = "has spaces"
    }

(Also, with C# 6's new abilities around constructor type inference, the type parameters may now be superfluous. I'm not certain, though.)

The access modifier "private protected" appears to mean "only derived types that are also in the same assembly."

bruceboughton3• 12 years ago

Good explanation, thanks.

I don't understand the advantage of the dollar syntax though. One character shorter, and makes it look more object-y, obscuring the perf difference.

jameshart4• 12 years ago

What's the value of using symbols instead of string literals to reference dictionary keys?

It replaces a 'magic string' with a 'magic variable name', which is worse than the normal solution for magic strings, which is to move them to a constant.

If I have code in one place that says:

   dict["key"] = "value";

and code elsewhere that says:

   var value = dict["key"];

I can make that code better today by adding

  const string KEY = "key"

and then using dict[KEY] in both places. I can change the key in one place, and if I misspell the constant name in either location then the compiler tells me I have a problem.

With the new syntax, I can now write

   dict.$key = "value";

and

   var value = dict.$key;

but if I go ahead and change one of these:

   dict.$newkey = "value";

I'm not going to get a compiler warning when I try to read $key (am I?). Unless there's some smart tooling support, where's the win here?

Key symbols aren't becoming a new type - I don't get to write

   var key = $key;
   var big_key = ["key with spaces"];

(so far as I'm aware - though I actually quite like the idea of a datatype that represents this kind of non-manipulable string identifier)

I guess the new .$ syntax combines with the null-propagating ?. operator, so you could have nested dictionaries and access them with:

dict?.$subdict?.$subsubdict

which looks... horrible. And suffers from the fact that there's no null-propagating equivalent index access operator, ?[], so I can only use this trick on keys that can be written as C# symbols.

I really feel like I'm completely missing what the use cases are for this capability...

gambler3• 12 years ago

I feel the same way. Too many corner cases, not many I deal with very often.

So far null propagation seems like the most useful feature for cleaning up cluttered code I'm used to dealing with.

Auto-property initializers are nice, but the syntax looks a bit ugly and I don't see them making that big of a difference in readability. I would rather see something that tackles the ugly-but-necessary construct I see the most: lazy-loading getters. Generic memorization of methods and properties would be even more useful. And yet even more useful would be something that could be used for both memoization and transparent caching:

  [Cache(For = 1000 /*milliseconds*/)]
  public GetSomethingFromDB(){ ... }

That would be tough to implement well, though. Unless they added Python-like attributes. Which would give us memoization, caching an a myriad other things.

Yrlec• 12 years ago

You might find these two links interesting: http://stackoverflow.com/questions/3180685/how-can-i-make-me... https://bitbucket.org/Yrlec/funccache

The first one is an answer I wrote on SO and the other is a library I wrote a couple of years ago. Both are are different solutions to the caching problem you describe.

bruceboughton3• 12 years ago

Lazy<T> is quite useful for lazy-loading/memoization.

sebastienros• 12 years ago

To answer this, the nice thing with Roslyn that is not explain in this blog is that it's also an API that you can extend with plugins. You project can contains them and they will have access to the AST at compile time, altering the compiled logic.

So in your example you could create one to detect your attribute and inject custom logic instead. You can unleash the full power of AOP at the compilation level.

pjmlp• 12 years ago

I think it is a consequence that programming in the large is complex and we all like our little feature to reduce boilerplate, while allowing for higher abstractions.

In languages that allow for full macros, many of those features can be implemented as library instead, which also creates the problem everyone has their own little DSL.

Anyway looking to the history of computing, all mainstream languages that started simple as a movement against complexity of some sort, ended up becoming more complex release after release.

zwieback• 12 years ago

Looks good but I don't know if I'll be able to keep these fresh enough in my head to be able to use these things without looking them up. Trying to keep up with the explosion of features in the curly brace languages starts getting really hard. Moving between low level FW (C), desktop apps (C++/C#) and Android (Java) something will have to give, my code will probably continue to just look really 2005-ish.

I really like the what the monadic null checking does but aesthetically it looks pretty ugly right now.

greatdox• 12 years ago

Well it is nice that C# 6 becomes cross platform, can someone please explain to me the license behind it?

Microsoft usually does the license thing that takes away some of your rights. Is it the Apache2 license or something else? What are the limitations on this project?

Thanks in advance.

danabramov• 12 years ago

The new compiler is Apache 2.

platz• 12 years ago

This is perhaps a bit trollish but hopefully someone will get some enjoyment out of it.

http://tomasp.net/blog/2014/csharp-6-released/

bananas• 12 years ago

Great read actually and definitely on topic - thanks for posting :)

Spearchucker• 12 years ago

Not as familiar with C# as I am VB.Net, but this (the before scenario) strikes me as a little odd (incorrect, or not the whole story, maybe?):

Readonly properties require less syntax.

Before

private readonly int x;

public int X { get { return x; } }

The only scenarios where I require readonly properties are where I set or otherwise calculate a private variable at runtime, and then enforce readonly to the public getter.

In the example above, it looks like the private variable is readonly, and must therefore be initialized with a value that cannot be changed. Am I reading this correctly?

gnaritas• 12 years ago

Yes; they can only be written to by a constructor.

jksmith• 12 years ago

Hjelsberg is continuing the tradition from Delphi that "less is less." Golang, stay disciplined and focused my friend.

django-fanboy• 12 years ago

What ever new feature C# includes, people will still hate it, whatsoever.

Hominem• 12 years ago

Seems like 6.0 is all about reducing boilerplate. Those default constructors and null checking will probably save me hours of typing as the ctor that does nothing but set stuff and null checking properties all the way down are such common code patterns.

louthy7• 12 years ago

I think Declaration expressions are a mistake and proper support for tuples (and pattern matching) shold have been put in. It feels like an inbalanced expression with the result on the left and the right:

    var success = int.TryParse(s, out var x);

I'm a bit 'meh' about Primary constructors, Auto-property initializers, Getter-only auto-properties. It seems a bit messy and incomplete. Personaly I don't use properties anymore and just use readonly fields with constructor initialisation (which is enough to capture the property setting logic). What I would like to have seen in this area is 'readonly' classes, with mechanisms for cloning objects using named parameters for partial updates:

    readonly class ReadOnlyClass(public int X, public int Y, public int Z)
    {
    }

Usage:

    ReadOnlyClass obj = new ReadOnlyClass(1,2,3);
    ReadOnlyClass newObj = obj.X = 10;

Instead of the current system for creating immutable classes in C#, which becomes quite unweildy and error prone as the number of fields grows.

    class ReadOnlyClass
    {
        public readonly X;
        public readonly Y;
        public readonly Z;

        public ReadOnlyClass(int x, int y, int z)
        {
            X = x;
            Y = y;
            Z = z;
        }

        public ReadOnlyClass SetX(int x)
        {
            return new ReadOnlyClass(x, Y, Z);
        }

        public ReadOnlyClass SetY(int y)
        {
            return new ReadOnlyClass(X, y, Z);
        }

        public ReadOnlyClass SetZ(int z)
        {
            return new ReadOnlyClass(X, Y, z);
        }
    }

Usage:

    ReadOnlyClass obj = new ReadOnlyClass(1,2,3);
    ReadOnlyClass newObj = obj.SetX(10);

I think 'using' static members will be a huge win for creating functions which appear to be part of the language. For example I use the following to do type inference on lambda expressions:

    static class lamb
    {
        public static Func<T> da<T>(Func<T> fn)
        {
            return fn;
        }
    }

    var fn = lamb.da( () => 123 );

I'v tried to make it look like part of the language by making it all lowercase, but it's still a little odd. Being able to 'using' a static class in would be perfect for this kind of stuff. To be used sparingly obviously.

Expression bodied members, yes please! So pretty...

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

Typecase and Guarded Cases would be lovely too. Basically anything that enables expression based coding in C#. It would be nice if the LINQ language functions were extended too: count, take, skip, tolist. It's slightly less pretty when having to wrap the expression in brackets to call .ToList();

Hakeashar• 12 years ago

I would love to see pattern matching and at least some kind of tuple support. I don't know if it's ever going to happen in C# though...

The `using` static is actually really good news. I have seen people who seem to be really mad about it, but sometimes it would be nice to have, for example:

    // Something like Scala's 'Predef'
    public static class Id<T>
    {
	public static Func<T, T> Identity { get {  return x => x; } }
    }

and then do:

   using Id;

   var grouped = list.GroupBy(Identity);

Considering you can already open modules in F# (which are compiled down to static classes), it seems that feature found its way to C#. So maybe there is still hope for pattern matching and tuple support :)

Equivalent of F#'s record types would be also awesome, which is what you put as 'readonly class':

    type Person = { FirstName : string; LastName : string }
    let single = { FirstName = "Jane"; LastName = "Doe" }
    let married = { single with LastName = "Smith" }

louthy7• 12 years ago

Agreed on all counts . Not sure what the C# team's desire is for another classification mechanism (record types), but it could be seen as an opportunity to fix some of the problems of the past (mutable types, nullable object references).

Perhaps C#'s record type could enforce immutability on not just the record but anything it's assigned to (maybe by using 'let'). That would allow the old mutable way to co-exist with language enforced immutability. It doesn't seem like it would clutter up or modify any existing code either, so if you don't like it, you never need to see it.

Not sure how that would work when assigning to a class's member property/field. Perhaps you opt out of immutability (of the reference) with a 'mutable' keyword:

    class AClass
    {
        public mutable ARecordType Value;
    }

Functional languages also 'extend' the behaviour of a type by defining functions that work with the type. But with an object-oriented language like C# you'd still expect the functionality to come with the type I think. So I suspect it would have to look something like this:

    type Vector
    {
        float X;
        float Y;
        float Z;

        int Length => Math.Sqrt(X*X+Y*Y+Z*Z);

        Vector Add( Vector value ) => new Vector { X+value.X,Y+value.Y,Z+value.Z };
    }

So it turns the entire class into one big constructor (with everything public by default). All non-expression fields should be provided when you instantiate the object:

    let obj = new Vector { X=1, Y=2, X=3 };

I'd be very happy with that. Maybe I'll fork the compiler and have a go... if I can just find the time.... gah

jameshart4• 12 years ago

Expression bodied properties: the syntax feels slightly off for me because I can't really read the => the way I do in expression lambdas, as 'goes to' - it lacks the argument list. I can see why the syntax is as it is, there's no really good alternative, but it feels wrong.

There's no clear 'functional programming' benefit to the property syntax, either. Even though the syntax implies that Dist is logically some kind of a Func<double>, I still won't be able to write Func<double> f = Dist, because Dist is of type double.

I'm also concerned about the idea (only 'planned' for now, I believe) for the same syntax for methods which take arguments, though. That feels like it risks pushing developers into the pit of failure by encouraging them to write public methods that contain no parameter validation logic, just evaluation of a return value. It also means that the instant you want to add more complexity to a method you're forced to completely rewrite it in the conventional curly brace syntax.

Then there's the halfway world of using the syntax for a method which takes no arguments:

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

where now I can write Func<double> f = Dist...

louthy7• 12 years ago

Although I 100% agree with you on the expression based properties, the argument against that would be that it doesn't follow the norms for the language as a whole. First class functions are definitely an afterthought for C#, so making this a Func<double> would go against that I reckon:

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

I'm also concerned about the idea (only 'planned' for now, I believe) for the same syntax for methods which take arguments, though.

Where's this? I must have missed it. Or could you show what it would look like?

AndrewDucker2• 12 years ago

I've actually switched to using a Reply<T> for anything which models the TrySomething pattern.

So it looks like:

  var possibleInt = TryParse(s);
  if(!possibleInt.Success)
  {
    //Fail out early
  }
  var actualInt= possibleInt.Data;

(Our Reply objects also allow for messages to be passed up, so that various layers can report details of the error they bumped into, and the presentation layer can then display them.)

louthy7• 12 years ago

Looks like you're part of your way to implementing the Error or Either monad.

V-23• 12 years ago

Personaly I don't use properties anymore and just use readonly fields with constructor initialisation (which is enough to capture the property setting logic)

Yes it's enough if the property setting logic is only executed once during the lifetime of the object. So, it only works if they're supposed to be immutable.

Plus, public fields cannot be used for data binding.

Plus, you can't debug nor log whenever a field value is read.

Also, you can end up having to convert it into a property, and this involves various compatibility risks.

Meanwhile, there is no plausible scenario where you realize you must convert a property into a field.

What do you gain instead, with your design choice?

louthy7• 12 years ago

Yes it's enough if the property setting logic is only executed once during the lifetime of the object. So, it only works if they're supposed to be immutable.

They are. Dig out some of the talks by Rich Hickey on immutability, he tends to put it pretty concisely, better than I ever could. But primarily it's about capturing snapshots of your world at a particular point in time so that you have a consistent view of the world. So all objects should be immutable.

http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...

Plus, public fields cannot be used for data binding.

JsonConvert.SerializeObject()

JsonConvert.DeserializeObject()

That's all I need, or a .Select(). I don't use WinForms or any of the standard ASP.NET databinding stuff, it's ugly as sin. Even if I did, isn't there a LinqDataSource or something these days? Not sure if that would do the job, but I'd assume it would work with the results of a LINQ expression? Anyway, I don't really need that, and being able to reason about my code is more important.

Plus, you can't debug nor log whenever a field value is read.

Never caused a problem, there's always the code that reads from it. Stick your breakpoint there. Also when you use immutable structures throughout, your bugs tend to not be in the 'values' (i.e. an immutable structure).

I tend to be breakpointing in the ctor if anything to check the setter logic or input values. Once the object is set, that's it. No need to keep checking.

Also, you can end up having to convert it into a property, and this involves various compatibility risks.

Fields an properties are incompatible? How?

What do you gain instead, with your design choice?

* I can pass an object to another method and know it's not going to change it without my permission.

* I don't have to analyse the inner workings of a class to find out how the state is going to be changed when I call a method on it.

* I can pass the same object to two threads running in parallel knowing that there won't be problems with the two threads writing to the same object..

* I can easily write transactional code and 'rollback' when it fails.

* I can write pure functions which makes it easier to test my code.

It's much easier to reason about a data structure if you know they won't change basically. There's huge advantages to that. Personally I find it makes my code more reliable and easier to compose and manage long term.

I agree it's not all sweetness and light using immutability with C#. There's more boilerplate than necessary and there's very little in the language to help the process.

Personally I think it's worth it, YMMV.

Pxtl3• 12 years ago

I looked at this earlier - on the one hand, I like that they're directly tackling known pain-points in the language. The declaration expression "out var x" thing is, imho, great. The TryParse syntax has always been a problem because you have to declare the variable the line before, which means no type inferencing and whatnot. Also, good for casting as they show.

Using static is great - finally we've liberated the verbs in the kingdom of nouns.

However, some of them have really ugly syntax. I know they wanted to get rid of the boilerplate problem of declaring and setting into a read-only member, but the primary constructor syntax is monstrous - declaring local variables inside of your constructor? Really? I feel like just having a "readonly set" access modifier on properties (both auto and explicit) would have been sufficient.

The new dictionary accessor seems silly.

Exception filters seem just as pontless in C# as they did in VB (nesting an "if/else throw" into a catch clause wasn't too hard).

The crazy null ?. operator I'm unsure about... that one I'll have to use. I've run into the problem enough times to see why they did it, though.

theflagbug• 12 years ago

Exception filters aren't pointless. They preserve the stacktrace, meaning the debugger will break at the original throw and not the throw; in your catch (I'm on mobile so I don't have a code sample, sorry, I hope you get what I mean)

Pxtl3• 12 years ago

Throw in a catch block with no exception argument preserves stack-trace.

That is

catch(Exception ex) {throw;}

Rethrows without meddling with ex.

Locke16896• 12 years ago

Thanks for the feedback, Jon!

FYI, we have discussion threads on http://roslyn.codeplex.com.

C# 6: First reactions

Related Stories