You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The compiler will produce a warning/error despite of the fact the pattern is exhaustive.
API Proposal
Any of the following would be acceptable
allow the compiler to generate the default branch if the pattern is exhaustive. for example it could be throw UnreachableException by default
add an attribute like [ExhaustivePattern] that turns the warning off. For example, we are sure that the value comes to us are West or East, and never equals to North, South, how about we tell about that to the compiler? maybe the JIT will manage to produce more optimal code based on this assumption
skashtanoff
changed the title
[API Proposal]: Add native support for exhaustive enu-based switch expressions
[API Proposal]: Add native support for exhaustive enum-based switch expressions
Oct 13, 2023
allow the compiler to generate the default branch if the pattern is exhaustive. for example it could be throw UnreachableException by default
The compiler already generates a branch throws SwitchExpressionException, with a warning about it.
add an attribute like [ExhaustivePattern] that turns the warning off.
Currently attributes can only be applied to constructs with compiled form in IL, like methods and fields. It can't be applied to statements inside a method.
Background and motivation
Now (.NET 7), if we have a
enum
:Then when we use it in
switch
-expression:The compiler will produce a warning/error despite of the fact the pattern is exhaustive.
API Proposal
Any of the following would be acceptable
throw UnreachableException
by default[ExhaustivePattern]
that turns the warning off. For example, we are sure that the value comes to us areWest
orEast
, and never equals toNorth
,South
, how about we tell about that to the compiler? maybe the JIT will manage to produce more optimal code based on this assumptionAPI Usage
Alternative Designs
No response
Risks
backward compatibility
The text was updated successfully, but these errors were encountered: