The Future of C#

The Discussion

• 

  Please add new C# features in Unity Game Engine.

• 

  What happened to the requested feature of Enum contraints for Generics? (already present in F#)

• 

  @AnilApex:It depend on Unity, not microsoft. Unity's .NET engine was outdated

• 

  Is this going to be part of the live broadcast?  It overlaps other talks on the main page.

• 

  It seems they threw this out from the live broadcast schedule... sorry, but this really sucks! The interviews with Seth are less important than this one IMHO. BAD DECISION!

• 

  ... very upset.  I set aside some time in my day to get the news on C# development... they had time for other nonsense that one cared about, yet they could not cover something incredibly important to a great portion of the community?

• 

  Is there a story around the Roslyn code analysis (and now code generating!) NuGet packages being supported by Visual Studio Code? Wondering if there is a future there or if this is a feature that is very much tied to Visual Studio.

• 

  @digiduck -- yup! We'll be working on that.

• 

  Can we please have inline XML like VB? That's a huge advantage for us who are still working on enterprise platforms.

   

• 

  How do I enable all the features shown by Mads in VS15 Preview ?

• 

  @topskarma
  
  http://www.strathweb.com/2016/03/enabling-c-7-features-in-visual-studio-15-preview/

• 

  @bkboggy: Which feature are you talking about?

• 

  Thanks for your Presentaion.

  When will you finish the work of native compilation  of all  .NET ?

• 

  Obviously sbyte is in C# for interop with the popular but low quality language called Java that does not even have unsigned byte.

• 

  I was hoping to see better type inference especially now with tuple return values.

  Is it still going to make it into C# 7?

• 

  I have used "sbyte" FYI. I'm glad its their ;)

• 

  What will the C# team do when they run out of features to copy from F#? It's easy for them to copy F# features because it provides a fully tested .NET implementation of many ML language features. Had there not been such an implementation so readily available, these features would have taken many more years to appear in C#.

  As more and more ML-like language features are added, C# starts looking like a poor man's F#.

• 

  @Phylos
  >C# starts looking like a poor man's F#.
  
  No, that's only the part you understand of C#. C# 7 can be used a 'poor man's F#' by an F# developer, but C# also has tons of features -that enhance both performance and code quality- that are a pain to emulate in F#.
  
  There's nothing wrong with seeing how things work out in other languages, and primarily borrowing features that have already proven to work, before accidentally polluting your language with things that don't. Enriching C# was part of the reason why MS started funding F#'s development in the first place.
  
  However, I don't feel like C# 7 has been so much more influenced by F# than earlier versions. Pattern matching and tuples are hardly F# (or even ML) exclusives. Actually, back in the .NET 4.0 days, when the old Tuples were added, they were heavily influenced by F#, part of the reason they were made reference types (a pretty clear mistake in retrospect) is that F# tuples are reference types and it makes interop between C# and F# easier.

• 

  sbyte IS useful to match java or C signed char.

• 

  @AnilApex:

  The new features of C# have nothing to do with Unity itself. Unity is supported by the .NET Framework and if you use C#, u will be able to use the new features in future automatically ;)

  Greetings!

• 

  Any chance for a 'switch' to return value, like in proper functional languages? Or, I don't know, to introduce something new like 'rswitch' or whatever?
  And what about exhaustive pattern matching? Like some clever compiler trick for specific types...

• 

  Time: 0:33:55
  Try always false "pred" and have a IndexOutOfRange
  we love c#7, but also love perfect code.. like:
  
  static int FindLast(int[] list, Func<int, bool> pred)
  {
  int i;
  for (i = list.Length - 1; i >= 0 && !pred(list[i]); i--);
  return i;
  }
  
  include -1 return
  
  
  

• 

  @jcdev: returning -1 isn't feasible (possible) for the final version, as they're going to return a ref to an element of the array. Torgersen did mention "So if I go over the edge it's gonna go over the edge and throw and exception. Who cares. ... It's DEMO code!". Throwing an exception is still the best of the straightforward ways to handle overflow there (another way would be returning a value that can signal the lack of matches, but it doesn't look so straightforward for "ref int" returns?), best he could do is throw one that more obviously tells the user that no element matched their predicate. The code he wrote is also faster than yours (for use cases where the predicate will always match at least one element). Not saying it that speed difference would matter at all in more than 0.00000001% of use cases.

• 

  All of that looks nice, except one small thing: TOO LATE. 14 years are too much to jump on a scene and show new focuses - there is enormous amount of code already written using BCL, so nobody will change his code and (more important) nobody will change BCL (to accept "modern" features and change API).
  And what's double disappoints that C# team invented practically nothing - all "new features" exist TENS of years in another languages! Multiple returns, return reference, pattern matching, local functions, interpolating strings... what a rocket science here to realize that all of it MUST HAVE features for production language?
  
  (about thinking "To implement or not") Scratching head once is a wisdom. Scratching head twice is a slowpoke. Scratching 14 years... name yourself.

• 

  @yep: i understand your point, but, a code that throw exception for a search is a ugly thing for me, the correct behavior must be the ability to return a "pointer Zero", like others languages.... if i need a "try catch" for code like the DEMO then i prefer to return an index.

• 

  @Vincent: It's true that all this things existed years ago, but not exist one language that include all feature. Of course is my personal opinion, i feel excited when my prefered programing language is improved. How know.. maybe C# will be the first language that have all of this wonderful things that exist 10 years ago..

• 

  @Mineshr "C# also has tons of features -that enhance both performance and code quality- that are a pain to emulate in F#." - Could you give an example?

• 

  @Vincent: As jcdev mentioned, I’m curious,
  First question: Which language had named/typed-tuples, ref returns, pattern matching, local functions, string interpolation (and linq, async methods, extension methods etc. and an IDE with top-notch editing, autocompletion and debugging support) 14 years ago?
  Second question: Which one beside C# has them today?
  
  @jcdev: I think the current proposal for ref returns is primarily intended for situations where you can expect to receive a valid ‘address’. If you can’t, you’re probably better off using traditional methods at this point. https://github.com/dotnet/roslyn/issues/118
  

• 

  Insanely cool stuff, really love where C# is going. And I say that as one of those who still has to work on not terribly well written VB6 applications much of the time.

• 

  Excellent stuff

• 

  @asik Stronger inheritance (ability to implement 2 instances of the same generic interface with different type parameters), support for implicit conversions, far more convenient handling of pointers (try to declare/use a pointer to the address of an array in F#), unrestricted ordering of definitions (far better for prototyping). A few of the things C# has over F#. Not to mention features like the VS debugger's ability to interpret C# expressions (in C# if you want to get the value of an expression during debugging, you just highlight and pull it over to the watch window).

• 

  Except for ref returns, all features are pretty handy and some what 'about time' for C#.

• 

  I miss covariance the most from F#, but that's because I abuse it in C#, they work so neatly combined with extension methods.

• 

  Oh boy, I wanted to use that "NotifyPropertyChanged" thing on another project.  It was for a universal Web Form element.  It would also have gone greatly with that switch statement that has types:

  switch(x)

    case int i: ...

    case object [] l:

  That's cool!

• 

  @galenus: I have played around with pattern matching in the VS 15 Preview, and according to my experience, when you want to pattern match for a return value you use the match statement. You should use the switch statement when you want to pattern match for side effects. Is there a scenario where the match doesn't satisfy you but switch with a return value would?
  'let x = y match (...)' is basically 'let x = rswitch(y) {...}', with a bit cleaner syntax due to the lack of support for fall-throughs.
  
  https://github.com/dotnet/roslyn/blob/features/patterns/docs/features/patterns.md

• 

  Yes I have same opinions. I see Java dying.......

• 

  Although you are providing clever C# syntax for functional concepts (e.g. matching), you should also provide alternative functional syntax. There were several references in the video to Javascript; Javascript (i.e. ES6) is providing functional syntax to some of their new functional enhancements.