switch expression: Warning CS8524 issued although all cases have been covered

[SetTrend]

switch expression: Warning CS8524 issued although all cases have been covered

[CyrusNajmabadi]

There should be a fix offered here.

[jjonescz]

The warning is correct, you can do this:

Orientation orientation = (Orientation)3;

[SetTrend]

@jjonescz: You could also do anything that's valid for an integer. Yet, who would do that?

I don't think it's reasonable to warn about hypothetical assignments. It would make more sense to warn about assigning invalid values to an enum type.

[jjonescz]

I don't think it's reasonable to warn about hypothetical assignments.

In that case you should suppress the warning for your whole project or solution.

It would make more sense to warn about assigning invalid values to an enum type.

There might be an analyzer for that. But it's an explicit cast, so it should be obvious you are doing something advanced and warning doesn't seem necessary.

Otherwise this is a language design question, those should be discussed in https://github.com/dotnet/csharplang first. Thanks!

[SetTrend]

With all due respect, the current warning text doesn't make any sense to this regard.

In the end, it all boils down to "add an anonymous switch case". Period. Nothing else.

Anything else, like the current "you are missing this or that value" endlessly is just a ridiculous cat-and-mouse game. You would end up adding 32768 switch cases.

Have you ever thought about providing a quick fix for remedying this warning by adding all the corresponding switch cases? The current warning message ("you are missing a particular value") is plain nonsense.

[jaredpar]

re-open for IDE fixer

[Cosifne]

New feature/Temp put under Sam's bucket because it's related to CodeStyle.

[sharwell]

@CyrusNajmabadi It seems like the fix here is project specific. For example, in Roslyn the fix would be throwing ExceptionUtilities.UnexpectedValue, but that method doesn't exist generally.

[sharwell]

After reviewing the SharpLab output for the original code sample, I'm doubting our ability to improve upon the current behavior. Before implementing a code fix, I would need to see a proposed code fix that achieves the following:

1. The performance matches the current behavior (the exception is thrown from a different method, or the use of a throw helper is known to no longer provide specific value)
2. The exception type and message is of similar quality to the current one
3. The clarity of the switch expression is not negatively impacted