The future of C#

Download this episode

Download Video

Description

We’re back! With C# 7.0 and Visual Studio 2017 just recently shipped, we paint the big picture: let’s lay out where the C# language and tooling experience is headed, and show early glimpses of what we’re currently working on.

For more information, check out this course on Microsoft Virtual Academy:

Day:

3

Session Type:

Breakout

Code:

B8104

Room:

WSCC Hall 6E (1215)

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image
      Vlad

      Are there plans of returning Anders Hejlsberg to C# design team?
      There is a big list of changes planned for C#, an opinion of the language inventor should be very valuable.

    • User profile image
      Marcel Veldhuizen

      Will the video be coming online in higher quality? Some of the code snippets are a bit hard to read right now.

    • User profile image
      vRITHNER

      Hi Guys,
      I always love your videos but this time, the low quality MP4 makes me not. The code is readable only when dustin is zooming. 
      Please at least for next time use medium or high quality.
      Thanks 

       

    • User profile image
      cordelllawr​ence

      Awesome stuff. Keep up the great work. 

    • User profile image
      Adam Wright

      Good talk, I liked most of the things. I don't think that encouraging changing Interfaces is a good thing at all. I really dislike the being able provide default method implementations for new interface members. I think this will promote bad habits. I'll likely just not use the feature. Thanks for what you guys do. The talk was good. I do like the other things you are thinking of like extension everything and record types.

    • User profile image
      SolvingJ

      Very excited about many things. Tuples... beautifully done IMO. Pattern matching also nicely done. I also think default interface implementations are a key step forward for the language. It's helped us dramatically in Java8, where extension methods are uglier than C#, but even in C# there are things ext methods can't do.  I understand the opposing point of view, but still agree with the decision.

    • User profile image
      ANewDev

      I'm glad i ported my Java project to C#, this language has a bright future

      Any words on CoreRT ?

    • User profile image
      dumky

      @Vlad: Definitely. Anders Hejlsberg is actually still involved with the C# design, although not at the granularity of weekly discussions. We review the progress of language design with him every two or three months.

    • User profile image
      UweKeim

      I'm impatiently looking forward for "Extension everything" to be available.

    • User profile image
      Vitaliy

      I don't understand for what reason interface can have body implementation now, this feature was organaized in abstract class, i don't like this idea it's not cool.
      Interface MUST have only abstraction of methods or properties

    • User profile image
      Shawn

      Vitaliy, implementation on an interface is often called a mixin and is found in many languages. This way you can have most of the benefits of multiple inheritance while avoiding the diamond problem.

      As a (somewhat contrived) example where it could be useful, say you have some ISizable type objects where the interface has a Height and Width and calculates an Area of a bounding box. Almost all implementations just multiply height and width to get the area. If you define a simple interface, you'd have to redefine the calculation of Area on every implementation.

      Currently you can get around it somewhat with extension methods. The addition of "extension everything" would help with this and you can define the extensions in the same namespace so they are auto-imported. But at that point why not just have it on the interface? If Area is a fundamental part of the interface, it's nice to have it there vs off in a separate extension method. And if you're overriding the functionality in your implementation class, I believe a method defined on the class with the same name will override the extension method, but again it isn't as obvious what's going on since Area isn't actually in the interface.

    • User profile image
      Eric Rushing

      As a hard-of-hearing individual I would like to see captions on this session video.

    • User profile image
      Sava

      Great job of evolving the language, the first time something doesn't feel right is the default implementations for interfaces. Cons seem to overcome the pros.

    • User profile image
      bitwacker

      Anybody know where we can get more information of "extension properties"? See: https://twitter.com/davidfowl/status/866167402655916034

    • User profile image
      Camilo

      Nice stuff, loving the tuples and very much looking forward to the performance enhancements planned, I've found myself performance tuning a lot with C#.

    • User profile image
      Jose

      What happen if I want to implement two interface with an equal name method, both with different implementation? Is there any conflict? Which method is selected by default?

      Regards

    • User profile image
      Walt

      TLDR: "now in c#, many ways to play with Tuples... a type that's not even included in the language". grrr

    • User profile image
      AbelPereira

      Oh, Java and Swift interop, now I get the motivation for the crappy interface feature. I thing you should simply let Miguel's team have a bit more work and do not pollute C# with stupid features.

    Add Your 2 Cents