Coffeehouse Thread

55 posts

Mads Torgersen @ NDC London : The Future of C#

Back to Forum: Coffeehouse
  • felix9

    So, Mads is doing this interesting presentation http://ndclondon.oktaset.com/t-11783

    according to Twitter reports, mainly from https://twitter.com/randompunter

    Read only auto properties, multiple return values, null checking, etc

    and stuctual typing is 'on the radar', whatever that means.

  • FuncOfT

    Of all the things that should be live on C9 ... this is one of them. 

  • Blue Ink

    Structural typing could be huge, if they get it to work with native types. It would finally put the old "INumeric" issue at rest.

    Fingers crossed.

  • felix9

    well, structual typing was not something Mads talked about in the presentation, its just https://twitter.com/randompunter asked him after the talk, and Mads answers with some vauge "on the radar" stuff, so ...... Tongue Out

  • wkempf

    Wish I could see the talk. This bit I found confusing from the slide without explanation:

    public class Point(intx, inty)

    The "maybe operator" ( ?. ) would be a very welcome addition.

    bar = (foo?.Bar?.ToLower() ?? "");

    Fixing the null mistake at this point isn't really possible (i.e. making even references non-nullable by default), but ?. at least gives us the tools to deal with cleaning up our code.

    A couple of things tweeted made me wonder. "We want to get rid of FXCop". Really? And replace it with? Lint tools are invaluable, but you don't want your compiler doing it. "Build in code contracts". Would love details about that. The current Code Contracts work OK, but there's definite shortcomings to them being an "add-on" as opposed to being part of the language. However, making them part of the language would have an even bigger impact on existing code. Still, Code Contracts are under-utilized. If they were part of the CLR proper and were fully exposed throughout the BCL we would likely see an extremely big improvement to code quality.

  • exoteric

    , wkempf wrote

    Wish I could see the talk. This bit I found confusing from the slide without explanation:

    1
    public class Point(intx, inty)

    This looks similar to F# constructor syntax Smiley

    http://msdn.microsoft.com/en-us/library/dd233192.aspx

    , wkempf wrote

    The "maybe operator" ( ?. ) would be a very welcome addition.

    Wasn't this null-safe operator part of Cω? It looks very useful indeed. In F# it's less of an issue because types have to be declared as nullable - except for all other "foreign" types that are also nullable.

  • damianh

    re; FxCop - they want that static analysis upfront and realtime via Roslyn. Not a seperate analyser that happens at build / on request

    re: CodeContracts - same as above instead of the ILRewriting and seperate static analysis is does now.

    The disappointing thing I took from this was there will be no ability to do language extensions.

  • wkempf

    @damianh: Having FXCop stuff "up front", i.e. in the IDE, would be handy indeed, but I still want to be able to enforce the rules at build time. So, I can't get behind that. Code Contracts have three parts: the physical representation of the contracts in the code/IL, runtime checking of the contracts and static analysis of the code. What you just said sounds like integration of the static analysis inside the IDE is the main goal. Details about IL Rewriting are not really that relevant here... the "just in time compilation" could still run through an IL rewriter. I get that they probably want to do away with IL rewriting, but that doesn't address the things that could truly be addressed if Code Contracts were made part of the language. And, I would also like to enforce the static analysis of contracts at build time, just like the FXCop analysis.

    @exoteric: Having types default to non-nullable would be nice, but that doesn't remove the usefulness of the ?. operator. After all, F# has a maybe monad for a reason.

  • FuncOfT

    , wkempf wrote

    LMFTFY:

    1
    public class Point(int x, int y)

    The "maybe operator" ( ?. ) would be a very welcome addition.

    1
    bar = (foo?.Bar?.ToLower() ?? "");

    Just a default constructor syntax ... good to have.  Saves wasting some typing in many cases, but not all.

    Why not just "?" instead of "?."?

  • exoteric

    @wkempf: Of course not. As long as there are nullable types this operator makes sense. It makes sense on optional values too, I think.

  • Blue Ink

    , FuncOfT wrote

    *snip*

    Why not just "?" instead of "?."?

    That would conflict with the conditional operator.

    Also, while not a compelling reason, the "?." operator is already used by other languages (Kotlin, for instance).

  • bondsbw

    Interesting that "?." was shown.  I figured ".?" would have been the more natural choice for C#.

    Assuming "?.", typing a question mark would now render 3 legal definitions:

    • the beginning of a conditional operator, ? :
    • part of the null coalescing operator, ??
    • the new null-safe dereference opeation, ?.

    In the first two (current) cases, the type of the expression following the operator would be the same* so Intellisense (I would think) would compute once and display the same list of options if the second ? is added.  But this third case means that a completely different set of options is available.

    On the other hand, if ".?" were chosen, both "." and ".?" have the same meaning as far as Intellisense is concerned and again it could take advantage of computing once and displaying the same list of options if the "?" is added.

    That's just how I think though... I'll go ahead and assume the C# team is smart enough to figure it out either way. Smiley

    * well, this is true only assuming that the expected type of the expression is known at that point.  But if the LHS of the full expression is typed "var" for instance, the ? : operator wouldn't know its expected type while the ?? would due to the type of its first operand.

    PS - Meh, now that I think about it I'm not even sure if Intellisense actually does much in the way of type checking its suggestions.  I'm getting so used to languages like F# and Scala that are built around type inference that I assume every language can do it if it tries really hard.

  • felix9

    here is another report from https://twitter.com/adamralph http://adamralph.com/2013/12/06/ndc-diary-day-3/

    The Future of C# with Mads Torgersen

    The NDC Wi-Fi was put to the test during this talk with the C# Twitter stream seeing an explosion in traffic as Mads revealed, for the first time publicly, a range of features either set to be delivered in the next version of C# or at least under strong consideration.

    Unfortunately I was too caught up in the excitement to note everything down but after mining my memory and the Twitter feed, here is the list of implemented/potential language features (I'm sure I'm missing at least one of them):

    • primary constructors - public class Point(int x, int y) { }
    • read only auto-properties - public int X { get; } = x;
    • static type using statements - using System.Math;
    • property expressions - public double Distance => Sqrt(X * X + Y * Y);
    • method expressions - public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
    • params for enumerables - public Point Average(params IEnumerable<Point> points) { }
    • monadic null checking - if (points?.FirstOrDefault()?.X ?? -1) { }
    • constructor type parameter inference - var t = new Tuple(1,2); // infers Tuple<T1, T2>
    • inline declarations for out params - public void Foo(out var x, out var y) { }

    I love all these features perhaps with the exception of the last one. Whist it doesn't negatively effect the language (although some of the audience were concerned about encouraging the use of out parameters) it doesn't really do much to achieve the stated goal of improving syntax for multiple return values. I was hoping for something like:

    public(int x,int y)Foo(){}

    But still, the rest of the features look awesome and I can't wait to get my hands on C# vNext!

  • MasterPi

    "I love all these features perhaps with the exception of the last one. Whist it doesn't negatively effect the language (although some of the audience were concerned about encouraging the use of out parameters) it doesn't really do much to achieve the stated goal of improving syntax for multiple return values. I was hoping for something like:

    public(int x,int y)Foo(){}

    "

    I agree...I was hoping that (T1,T2) would get processed down to a Tuple<T1,T2>, so it could be used as a return type. I just hate the use of "out".  Though, I wouldn't mind if you did public int Foo(out string x) returns (int, string) or something like that. Then a Double.TryParse could return (double, bool), etc..

  • bondsbw

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

    At first glance I thought "well this only replaces two curly braces with =>, so it's a zero sum game" but then I didn't realize the "return" was missing.

    So that makes me think... could C# just make "return" optional for the last expression in all method/getter blocks?

  • contextfree`

    What I would really like is something like "named anonymous types" ( Wink ). An expression syntax like {int x, int y} that could go anywhere a type is allowed, and could then be instantiated via new { x=2, y=3 }. You could declare a List<{int x, int y}>, ViewPage<{int x, int y}> (in ASP.NET MVC), etc. It's often you want to bundle a bunch of values without the obnoxious ceremony of declaring a FooResult or FooViewModel type, but I don't really like tuples because it's rare each value doesn't have a specific meaning you care about, besides its type and position

  • MasterPi

    @contextfree`: Basically, like in TypeScript where you can pass the blueprint for a JavaScript object? The only issue I'd see with that is that it'd be too permissive, that now that each value does have a specific meaning in relation to the others, you can pass around two types that both fit the syntax, but are still "different".

  • Liviuu

    I would love to see in C#6 some more meety features like:

    string interpolation

    pattern matching

    linq lamba expression support for statements ( inline ).

    more dynamic enhancements 

    anonymous objects that implements interfaces inline

    extending operators from outside of a type

    even more : support for syntactic macros?

     

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.