1.9 KiB
C# Language Design Notes for May 30, 2018
Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!
Annotating parts of a project
Roslyn starts out with about 2000 warnings. We may want to support nullable annotations for only a part of a project, so that you can gradually ease into them.
This touches on a core question: Are there separate opt-ins for consuming nullability (give me warnings please) and producing nullability (consider unannotated reference types to be non-nullable; "URTANN").
If we have a scoped "URTANN", then turning on warnings for the whole file would still have limited impact, until annotations start becoming abundant.
But we may also want to consider warnings to be turned on in a scoped way, at a certain granularity. Source files? Fine grained program elements? It might be better not having this, though, as it comes with the risk of introducing more problems (through annotation), without discovering it (because the consumption has warnings off).
T M(string s) => M2(s); // No warning because s is oblivious
[URTANN]
T M2(string s) => ...
The opt-in to warnings could be a "fake" error code that represents a category. We may not need a brand new dedicated command line option, but we're willing to go there.
- We agree that we are comfortable (for now at least) in opting in to the warnings at the whole project level only
- We agree that there should be a separate mechanism for opting in/out of non-null annotations (URTANN)
- We agree that URTANN should be attribute-based, and able to be applied (or unapplied, with a
falseargument) at multiple levels of program elements
Decision:
Let's have URTANN(true) implicit by default, unless you have another module-level URTANN. We can maybe auto-generate it if you don't have it already. It should be called NonNullTypesAttribute(bool).