-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open issue: how to mitigate break for length patterns? #5226
Comments
2 tasks
Discussed in LDM 10/13/2021: in short, all this complexity doesn't seem warranted. Sticking with the assumption of non-negative Length and accepting the compat break seems preferrable at this point. We'll have this break in an early preview so that we can revisit if real-world cases are reported. |
91 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Relates to PR dotnet/roslyn#56721
Relates to test plan dotnet/roslyn#51289
Switch
Current rules:
Proposed rules:
Negative branch:
In the DAG, we introduce the notion of an “negative branch” which means “only possible if Length could be negative”.
When we test for a Length: we get an “negative branch” if the branch bins only negative remaining values for the Length temp (this branch would be unreachable if the "Length is non-negative" assumption help). But we get a normal/real/positive path if the branch includes some non-negative remaining values for that temp.
We can represent this in the DAG by adding an extra no-op state on negative branches (it's a passthrough node with a special flag).
Impact
Those rules give us a warning, instead of an error, when an arm rests on test like
{ Length: -1 }
.They also give use exhaustiveness diagnostics that we desire on the positive domain.
But this approach is unable to produce exhaustiveness warnings on negative values that were missed.
{ Length: >= 0 } => ..., { Length: -1 } => ...
produces no exhaustiveness warning for missing-2
.Exploring alternatives:
If we wanted to do that, we might be able to instead use the non-negative integers domain for Length properties, until we reach a test that triggers the domain to be expand from there on in the graph (may be a usability issue since the graph isn't available) or the whole graph.
I think this would introduce undesirable exhaustiveness warnings in
case []: case [_]: case { Length: >1 }:
becauseLength > 1
is treated as a triggering test by definition above (it bins only negative values on one side). This was one of the motivating scenarios to restrict the domain of length properties in the first place.Users would have to write
case []: case [_]: case _:
instead.So if we really want to offer exhaustiveness checking on negative length values, we probably need a different definition of what tests trigger a negative branch.
is
patternsCurrent rules:
For
is
patterns we produce an "always matches" warning or a "never matches" error if the whenTrue or the whenFalse branch is unreachable.Proposed rules:
Add a new warning for
is
patterns: produce a "likely always matches" or "likely never matches" warning if the whenTrue or the whenFalse branch is reachable only by a negative path (ie. unreachable under non-negative assumption).FYI @alrz
The text was updated successfully, but these errors were encountered: