4 ms·
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 p
by lostmsu 6y ago
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.
- int_19h 6y agoYou 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.
- emodendroket 6y agoYeah, 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.
- twodave 6y agoFor 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