
What's New in C# 9.0 - pjmlp
https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-9
======
cpascal
> 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();
    

This is something I've long wondered why I couldn't do and I'm glad I'll be
able to in C# 9.

~~~
tandr
I wish other languages would adopt this too...

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

~~~
pjmlp
You can already use C# for scripting with previous versions.

[https://docs.microsoft.com/en-us/archive/msdn-
magazine/2016/...](https://docs.microsoft.com/en-us/archive/msdn-
magazine/2016/january/essential-net-csharp-scripting)

[https://itnext.io/hitchhikers-guide-to-the-c-
scripting-13e45...](https://itnext.io/hitchhikers-guide-to-the-c-
scripting-13e45f753af9)

C# 9 just makes it easier.

------
rafaelvasco
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;

------
zadkey
Record types seem like a direct borrow from F#. They even keep the
immutability and with-expressions.

------
domrally
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

~~~
0xcoffee
It was unclear to me from the article, if you don't set an init property
during construction, does it get default value or compiler error?

~~~
aliswe
Default value, just like if you do { get; private set; } and never set it, or
just { get; } and never do.

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

~~~
reader_mode
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.

~~~
pjmlp
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++.

------
majkinetor
New is patterns are nice:

    
    
        public static bool IsLetter(this char c) =>
            c is >= 'a' and <= 'z' or >= 'A' and <= 'Z';

~~~
8K832d7tNmiQ
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)
      {
          // ...
      }

~~~
ThePadawan
Do you have some more context for the before/after of the code?

I don't see a big win over

    
    
        if (e != null) {...}

~~~
WorldMaker
The bigger win I think for the `not` patterns will be anywhere you remove
constructions in the form:

    
    
        if (!(e is Class)) {/*...*/}
    

Sometimes the ! gets visually lost in the extra parentheses. The `not`
patterns should especially make it cleaner to write certain styles of DeMorgan
substitutions (!a && !b to !(a || b) type things) in ways that will be easier
to read.

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

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

~~~
Smaug123
It's increasingly looking like in ten years C# will contain F# as a subset, so
pattern matching is certainly not going away.

