I don’t think they’re just randomly throwing stuff at the wall. These are all things they’ve been talking about for years.

The C# language design process is very much in the open, so anybody can go and take a look at the rationale etc.

https://github.com/dotnet/csharplang

I think it suffers from the design by a self-selected committee now. Very little of recent changes have long-term vision behind them now, and seem to be quick patches.

Specifically, I just tried disabling 7.0+ features in an open source project I run, and we only actively used pattern matching for "is MyType inst", ref structs (hi Rust!, that one is really fundamental), and natively sized integers (which are still poorly supported by runtime).

Other sugar changes have uses across codebase you can count by fingers of one hand.

We also use unmanaged function pointers, but the feature appears ugly in many ways. For our purpose, I'd prefer a tiny bit more flexible DllImport (a hook to give it the dll path at runtime) over function pointers.

For contrast, I'm looking at the old C#7 and C#8 release notes--I can say our team frequently uses:

C# 7

  - value tuples
  - local functions
  - throw expressions
  - default literals
  - out variables

C# 8

  - switch expressions
  - using declarations
  - static local functions
  - asynchronous streams
  - null-coalescing assignment
  - enhance string interpolation e.g. via @$ prefix

You don't consider the more advanced pattern matching stuff to be "long-term vision"?

And it's not surprising that an existing large C# codebase wouldn't use many of those features. But for new projects, they are very nice.

Yeah, it seems clear to me that the long-term vision is importing a lot of functional features to make using functional patterns/immutable data easier. Which I think is an excellent choice because that stuff is super useful.