Revise unused variable warning rules

[alrz]

All the reasons for not flagging unused variables as unused variables are addressed by wildcards.

// A local variable that is written to is considered to also be read,
// unless the written value is always a constant. The reasons for this
// unusual behavior are:
//
// * The debugger does not make it easy to see the returned value of 
//   a method. Often a call whose returned value would normally be
//   discarded is written into a local variable so that it can be
//   easily inspected in the debugger.
// 
// * An otherwise unread local variable that contains a reference to an
//   object can keep the object alive longer, particularly if the jitter
//   is not optimizing the lifetimes of locals. (Because, for example,
//   the debugger is running.) Again, this can be useful when debugging
//   because an otherwise unused object might be finalized later, allowing
//   the developer to more easily examine its state.
//
// * A developer who wishes to deliberately discard a value returned by
//   a method can do so in a self-documenting manner via 
//   "var unread = M();"

Shouldn't this be revised?

[gafter]

You mean revised to introduce new warnings for existing code? No, not until we have warning waves so those new diagnostics are opted-into.

[DavidArno]

@gafter,

Do you have more info on these "warning waves", please?

[alrz]

@DavidArno #1580?

[DavidArno]

Great, thanks @alrz.

[drewnoakes]

The ability to opt-in to a stricter diagnostic here would have caught the bug fixed in https://github.com/dotnet/project-system/pull/9569 that reduces 0.3% of allocations during solution load in Visual Studio. Neither CS0219 nor IDE0059 would catch that one.