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

I wish other languages would adopt this too...

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.

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.

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;

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

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

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?

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

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

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

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

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

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.

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;

It could be a check for the lack of an interface rather than not null.

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?