# 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:**

1. `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.

2. No warning waves is `/warnversion:none`. All warnings is
`/warnversion:all`.
