Add draft spec for C# pattern-matching changes.#3361
Conversation
Co-Authored-By: Fred Silberberg <[email protected]>
Co-Authored-By: Rikki Gibson <[email protected]>
|
I think I've addressed all of the review comments. |
| This does not work today because, for an *is-pattern-expression*, the pattern variables are considered *definitely assigned* only where the *is-pattern-expression* is true ("definitely assigned when true"). | ||
|
|
||
| Supporting this would be simpler (from the programmer's perspective) than also adding support for a negated-condition `if` statement. Even if we add such support, programmers would wonder why the above snippet does not work. On the other hand, the same scenario in a `switch` makes less sense, as there is no corresponding point in the program where *definitely assigned when false* would be meaningful. Would we permit this in an *is-pattern-expression* but not in other contexts where patterns are permitted? That seems irregular. | ||
|
|
There was a problem hiding this comment.
note (from our talk today): i think we should support this. users will be able to say any of:
if (e is int)
if (e is not int)
if (e is int i)
// but not
if (e is not int i)
Despite that they can write:
if (!(e is int)) -> if (e is not int)
// but not
if (!(e is int i)) -> if (e is not int i)
It's a very strange inconsistency.
There was a problem hiding this comment.
We could do that but ONLY (1) for the is-pattern expression (no other places patterns could be used), and only (2) if the not is at the top level only. For other cases, there isn't any clear place that the pattern variables would be definitely assigned. If we did this, people would find these restrictions to be strange.
I'm OK considering this relaxation as a separate proposal to be considered later. Specifying it will be a bit convoluted: currently, pattern variables are only definitely assigned when the pattern matches.
In any case, the intent here is to check in a document describing what we already accepted and implemented for C# 9 (not that it cannot change).
There was a problem hiding this comment.
Agreed with Cyrus. It may make the spec convoluted, but I think the regularity would be worth it. We should definitely put this in the open issues tracker to make sure we don't forget about it.
333fred
left a comment
333fred
left a comment
There was a problem hiding this comment.
LGTM. Make sure to have a tracker for the is not int i part.
4 participants
No description provided.