|
|
|
|
|
|
by ljackman
2380 days ago
|
|
|
Thanks for the clarification on the final NRT behaviour. Just to say, my point about "didn't align with good taste" was itself lacking taste. I'm sure each of those features I critiqued made sense as they were proposed at the time and were just considering different use cases and tradeoffs. Did it drop the idea of assembly-wide opt-ins to stricter behaviour, meaning all NRTs can be reasoned about in the same way without considering a configuration flag somewhere like PHP? That does sound like an improvement. Doing the change gradually, without breaking existing code or requiring potentially-ecosystem-breaking opt-ins does seem eminantly sensible and user-friendly. I was being too harsh to C# here. Java's `Optional` doesn't even warn about it itself being null, for example. You need static tooling and code analysis for that. C#'s solution does at least try to solve that, albeit at the cost of more complexity. I said "monad-like" rather than "monadic" for that reason, but arguably it doesn't even go far enough to be considered monadic-like. Certainly this article would agree: https://blog.developer.atlassian.com/optional-broken/ |
|
|
There's three levels of opt-in/out:
* Source directives, for opting in/out a single scope (typically a whole file, but it can in be as small as a single method)
* Project file directive via MSBuild property, for opting in/out a single project/assembly
* The MSBuild property can be set in a Directory.build.props file, opting in/out all projects in a directory and its children
In the long term, this property will likely be implicitly set to true for new projects (and perhaps all projects in the very long term), but for now everything is opt-in.
Personally, I think that one of the biggest areas for tooling improvement is to better recognize when you're in a nullable-enabled context. It's pretty obvious when you look at source code, but when you've got a million LoC codebase and only a subset uses it, making developers aware of that is certainly a challenge.
The other interesting thing to consider here is that even if the C# compiler freezes all future improvements to NRT analysis, there is a level of breaking changes that will occur over time as packages and frameworks adopt the feature and rev their versions. This transformation won't be without pain for existing codebases, and some may never adopt the feature (especially if they're the kind of codebase that doesn't really modernize). Interesting times ahead.