The future of C#

The Discussion

• 

  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.

• 

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

• 

  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 

   

• 

  Awesome stuff. Keep up the great work. 

• 

  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.
  

• 

  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.

• 

  I'm glad i ported my Java project to C#, this language has a bright future
  
  Any words on CoreRT ?

• 

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

• 

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

• 

  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

• 

  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.

• 

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

• 

  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.

• 

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

• 

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

• 

  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

• 

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

• 

  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.

• 

  A note that the default interface implementation can still cause a breaking change as there's a chance you'll step on another interface's toes, requiring explicit implementation by the consumer.

  Love the new pattern matching features, feels like we're slowly moving toward structural typing so looking forward to seeing what gets implemented next there.

  Extension everything would be very nice, especially for operators. For example, would we be able to define an extension "+" operator on two int arrays? Will we ever get a way to do this generically (i.e. IAddable static "interfaces"/contracts)? We do a lot of multidimensional math at work, and have moved away from C# for many of these tasks which are just too cumbersome to script with.

  How about C#/AMP?

• 

  Wish you talked more about C# 7.2. I would like to hear what features you plan to introduce so we can have safe low level stuff and how this will work (specifically garbage collection etc.) . I found myself using pointers in C# quite often, so I am very happy to hear this announcement.

  In general I like all these new features but I wish more focus set on CLR performance. Thank you for all great work you guys put into C#.

• 

  you should take a look kotlin 's futures, and at least once time try to use intellij idea.

• 

  I think it'd be more proper to have:
  
  foreach (await var x in ...)
  
  Instead of:
  
  foreach await (var x in ...)
  
  
  In the first case the syntax reflects that you're awaiting a value in the sequence. It also fits the idea of "variable as a pattern"; in this case, an asynchronous pattern.
  
  The same argument goes for "using await", etc.