3.6 KiB
C# Language Design Notes for September 26, 2018
Agenda
Warning waves
Discussion
Motivation: Right now we consider adding a new warning to existing code to be a breaking change. We want a way to add diagnostics without it being a breaking change.
Solution: Some mechanism to opt-in to breaks ("warning waves").
For warning project levels, we consider "latest" to be the most common setting aside from "none". Most people who want all possible warnings will target "latest", and will only choose an earlier warning level number when the get a new warning that they can't fix at the moment for some reason.
Negatives: Seemingly unrelated warnings are grouped into a bundle that may be confusing. However, enabling individual warnings seems both a pain for users to do every update, and very difficult for discovery (where do users find the list of new warnings?)
When you haven't enabled the warning wave, we still want the diagnostics to appear, but we want them to be suppressed such that the IDE and tooling can see them, but the user does not (normally). Exactly what type of suppression we use is to be solved.
Q & A
One problem we'd like to address with warning waves is definite assignment of structs with private members where, due to various compiler bugs, the struct appears to be definitely assigned when it is not.
Q: Definite assignment diagnostics are always errors right now -- should we allow "error waves" as well?
A:
No, for now. Let's see if we can provide warnings for some of these issues without producing errors.
Q: Should warning waves be per-SyntaxTree or per-Compilation?
A:
Per-Compilation for now. The SyntaxTree level may be an interesting feature but there are no scenarios compelling enough right now that merit the additional complexity.
Q: Is the command line option case sensitive or case insensitive?
A: Case-insensitive.
Q: How does the IDE get access to info on the warning waves?
A:
The compiler should provide an API to get a list of all warning IDs in a particular wave. The IDE should also pull from the compiler resources to find the description for each particular warning. The compiler also needs to know which warning versions are valid. We also need an API for getting which warning wave a particular warning is part of, if any. Warnings in new language features are never part of a warning wave.
Q: What's the bar for adding a warning to a warning wave? Is it the same as whether or not we would have created a diagnostic if we were doing the feature for the first time now?
Conclusion
No. This will still cause users to do extra work, so we need to make sure that each warning we're adding is worth the change. We should also consider how much work will go into a particular warning wave and avoid overwhelming the user. Based on feedback we can dial the severity back and forth.
However, we should introduce high-impact changes as soon as possible to make it clear what kind of breaks users are signing up for.
Q: Do we want a "major" flag for upgrading language version only with major version?
Conclusion
No.
Q: Which warnings do we put in?
Conclusion
Let's do prioritization later, but don't spend too much time deciding exactly which one. In general, the system for adding warnings should go through LDM.
Q: What are the version numbers?
Conclusion
We aren't sure yet. "7.3.1"? "8.0.0"? Jared proposes Git SHA.
Notes:
-
csc /warnversion:with no warnversion could list all the possible warning versions with all of the diagnostic ids in each warnversion and the title of that warning. -
No warning waves is
/warnversion:none. All warnings is/warnversion:all.