C# Today & Tomorrow

The Discussion

• 

  Hey Guys,
  
  this is all very exciting, but where is the promised 'extends' keyword with ability to adapt an existing class or interface to another interface locally (within a certain code)?
  

• 

  you guys, and the Scotts Gang are the reason I watch every Build.

• 

  @Nick: Still working on that one. It's a big feature, and will require runtime changes, so if we can even do it, it's going to take a couple of years.

• 

  @waturrr: Awwww! :)

• 

  I summarized and reviewed what are the new features in C# 9. If you guys want to read: https://medium.com/@faruk.nane54/whats-new-in-c-9-fd975fbaab67

• 

  How soon do you expect records/data classes to have EF Core support? On day 1, or in a future release?

• 

  Love the pattern matching bits, the not pattern has been long overdue. Unfortunately, that's where it ends for me. Don't like the top level statements...makes it seem like I'm programming in a scripting language and makes me want to run as fast as I can in the opposite direction. Now, records... It will be another feature that is pretty useless and I'll explain why. When I'm writing an immutable type, my constructor validates the invarients based on business requirement. Due to this, records won't ever benefit me and, I'd imagine, people writing immutable classes won't be able to take advantage of it either. Sure the language feature that checks for nulls helps but that doesn't do anything for all the other data types.

• 

  Will there also be data structs then?
  Great job, congrats to the C# team!

• 

  A question about pattern matching.
  
  One benefit of the default (or discard) case is that it catches those scenarios where you forget to handle something. Does the compiler warn about that, or would it fall through?

• 

  Discriminated unions?

• 

  How to try C# 9.0 after installing latest .NET 5 preview, what is minimum VS version required? Any configuration in project?

• 

  I actually don't like the getting rid of the Program / Main boilerplate. I think that should be required. One could ask the question, "Why not remove other boilerplate code?" which could end up in a slippery slope that could lead to confusion for folks maintaining those apps down the road. It's only six lines, just leave it. 😉

• 

  Mmmm... data keyword will definitely conflict with variable name I am using in most MVC, API methods right now. Very minior indeed but what about prototype keyword instead?

• 

  I agree to DevSec's comment that removing the boilerplate code on Program / Main does not seem to be of much benefit.
  
  In fact at the first glance, it even makes it more hard to recognize now. So, if possible, focus on other more important areas to improve upon rather than this Trivial thing.

• 

  The new "init", "with", and the override return types are just LOVELY LOVELY, thank you so much for making our world so pretty.

• 

  I agree as well. Removing the boilerplate doesn't make much sense. It's better off leaving it.

• 

  I have 3MB internet. Even with lower quality settings these videos are buffering. I can watch Youtube videos and videos on other sites without buffering.

• 

  Great job getting rid of the boilerplate code without turning c# into an indecipherable mess.
  
  My only complaint is it would have been nice to recognize the community members who built the target-typed new feature as that is the one that will likely save me the most keystrokes.

• 

  I don't love getting rid of the boilerplate code, but during Build, someone in the chat pointed out that it's not really intended for real applications; it's more for simplifying demos & for educational purposes. The rest of us can keep using Main() the way we always have.

• 

  You guys really really need to have records implement == that call Equals.
  
  I hope the plan is still to have the record/data keyword able to be applied to structs as well.

• 

  Regarding the positional records, since there's the ability to have both constructor and deconstructor overloading, is it going to be possible to do this for positional records as well? From the syntax presented, it seems like it would only allow a single overload. For example, it would be nice to have a record that can be contructed both from (FirstName, LastName) or (FirstName, MiddleName, LastName).

• 

  Namspaces is taking up precious screen estate.
  Why can't I set it to 0 tabs in Visual Studio ?
  Why cant I have default namespaces as in VB.Net ?
  Good namning style is to have telling names for methods and variables.
  C# is not a help in this effort !
  

• 

  'init', while lovely, seems targeted as a very narrow case; why not allow inline initialization for read-only properties without any new access modifier ?

• 

  So the () constructor will take type inference from the left side, and the var keyword will take type inference from the right. This makes var p = (1,2) make syntactic sense (Although inference will fail). I'm not a fan of this sugar, and feel it, combined with the var keyword, is going to make code very difficult to read. One or the other, fine, but not both.

• 

  Great job with these features!
  
  Would love to see some changes to the constructor field initialization ceremony in the future (i.e. when using dependency injection).

• 

  I agree with the people saying that removing the boilerplate code on Program / Main is not a good idea. It just feels WRONG.
  
  Anyone wanting to use C# should have to at least be expected to learn the basics for goodness sake. C# isn't a scripting language, so I see no benefit from "pretending" that it is.