What's New in C# 9.0(docs.microsoft.com)
docs.microsoft.com
What's New in C# 9.0
https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-9
23 comments
I get the impression that Microsoft is dogfooding C# on a greater level than before beginning with Span<T> and Memory<T> in .NET Core 2.1 (among others), still clearly ongoing here in C# 9. It's almost like a paradigm shift where I note the .NET Framework of past focused on higher level features and evolving the standard library first and foremost. I'm not sure if it's just me though, or if not, what the reason behind this push actually is.
Span/Memory/ValeTask and friends were motivated by optimization push for ASP.NET core, they were serious about getting to the top of some benchmarks.
And from the experience with Midori as well, which got them first in System C# (M#), which also contributed to span and string_view papers for similar capabilities in C++.
From the top-level statement section:
> Top-level statements enable a script-like experience for experimentation similar to what Jupyter notebooks provide. Top-level statements are great for small console programs and utilities.
This is great for small, one-off scripts that can handle simple tasks for sysadmin work. I use Powershell for handling configuration changes on the CLI, but I don't write and save many scripts with it. Perhaps I need to learn more about the PS environment to fix that. Either way, I have a hunch that there are some tasks—which would be cumbersome in PS—that this new feature would make accessible.
> Top-level statements enable a script-like experience for experimentation similar to what Jupyter notebooks provide. Top-level statements are great for small console programs and utilities.
This is great for small, one-off scripts that can handle simple tasks for sysadmin work. I use Powershell for handling configuration changes on the CLI, but I don't write and save many scripts with it. Perhaps I need to learn more about the PS environment to fix that. Either way, I have a hunch that there are some tasks—which would be cumbersome in PS—that this new feature would make accessible.
You can already use C# for scripting with previous versions.
https://docs.microsoft.com/en-us/archive/msdn-magazine/2016/...
https://itnext.io/hitchhikers-guide-to-the-c-scripting-13e45...
C# 9 just makes it easier.
https://docs.microsoft.com/en-us/archive/msdn-magazine/2016/...
https://itnext.io/hitchhikers-guide-to-the-c-scripting-13e45...
C# 9 just makes it easier.
New is patterns are nice:
public static bool IsLetter(this char c) =>
c is >= 'a' and <= 'z' or >= 'A' and <= 'Z';the negated pattern is a bless for me, finally removing a lot of null checking into this short condition instead.
if (e is not null)
{
// ...
}Do you have some more context for the before/after of the code?
I don't see a big win over
I don't see a big win over
if (e != null) {...}Approaching natural language, in this case, gets things a bit more readable. I like it. Of course , for this example in particular , doing e?.(...) is better if the block of code is short;
[deleted]
It could be a check for the lack of an interface rather than not null.
The bigger win I think for the `not` patterns will be anywhere you remove constructions in the form:
Given those big wins, they alone provide a useful context of some consistency of having the `not` operator even for "simple" cases like (e is not null).
if (!(e is Class)) {/*...*/}
Given those big wins, they alone provide a useful context of some consistency of having the `not` operator even for "simple" cases like (e is not null).
It's subtly different in that the != version will call an overloaded != operator if one exists and the "is not null" (or the semantically similar but less self-explanatory pre-9.0 "is object") won't.
Init only setters are a dream come true. Property initializer syntax to me is very readable and lack of read-only support after initialization was the main reason i avoided using it
> In C# 9.0, you can omit the type in a new expression when the created object's type is already known.
private List<WeatherObservation> _observations = new();
I wish other languages would adopt this too...
Wow, function pointers is huge for native binding. Lot's of QOL new features as well. C# and .NET framework (core and future merged .NET) in general keeps delivering. Love the entire stack;
Not sure pattern matching will age well. It seems to promote anti-OO design, may cause the switch statement to devolve into if/else, and creates another way to do the same thing.
It's increasingly looking like in ten years C# will contain F# as a subset, so pattern matching is certainly not going away.
> Not sure pattern matching will age well.
I've been using pattern matching for around 8 years now and still love it.
> may cause the switch statement to devolve into if/else
What does that mean?
I've been using pattern matching for around 8 years now and still love it.
> may cause the switch statement to devolve into if/else
What does that mean?
Record types seem like a direct borrow from F#. They even keep the immutability and with-expressions.