Hacker News new | ask | show | jobs
by zigzag312 74 days ago
From what I've read, this is for the first implementation of unions, to reduce amount of compiler work they need to do. They have designed them in a way they can implement enhancements like this in the future. Things like non-boxing unions and tagged unions / enhanced enums are still being considered, just not for this version.
1 comments

This is the general pattern of how the C# team operates, IME.

    "Never let perfect be the enemy of good"
Very much what I've seen from them over the years as they iterate and improve features and propagate it through the platform. AOT as an example; they ship the feature first and then incrementally move first party packages over to support it. Runtime `async` is another example.
In the meantime I still haven't done any project with nullable references, because the ecosystem has yet to move along. Same applies to ValueTask for async code.
Which part of the ecosystem is blocking your projects from using nullable references? I find them very helpful, but the projects were all newer or migrated to new SDK.
What all projects?

It is relatively easy to find corporate libraries, or commercial products that still aren't using it, including Microsoft products still stuck in .NET Framework, or .NET standard 2.0.

If you want name shaming of commercial products with modern .NET, here is one, can provide more.

https://github.com/episerver/content-templates

You can use dependencies that aren't using nullable reference types in projects that use it. You can enable/disable nullable reference types per file, as it only influences static analysis. There's no runtime difference between a non-nullable reference type and a nullable reference type.