Add pattern-variables.md #4592
Add pattern-variables.md #4592
Conversation
|
Opening up this early due to possible interaction with improved def assignment proposal. |
proposals/pattern-variables.md
Outdated
|
|
||
| The following rules applies to any *primary_pattern* that declares a variable: | ||
|
|
||
| - The state of *v* is definitely assigned after *primary_pattern* if the pattern is irrefutable; permitting use after: |
There was a problem hiding this comment.
This rule should probably be moved to the previous section under is_pattern_expression. Because only at the top-level we can determine if a pattern always succeeds (at least that's how it works today). Of course, except for a var-pattern with a single variable designation which always succeeds regardless of the input type.
There was a problem hiding this comment.
Consider linking to those original/unmodified sections instead of replicating them here.
There was a problem hiding this comment.
There's no one place for this in previous proposals. We have three documents each of which mentioned definite assignment in prose.
In any case, since we don't want to add expressions to the mix just yet, I think we no longer need to specify definite assignment in this format.
|
I made a fairly quick pass over the proposal and didn't notice anywhere that it would conflict with "improved definite assignment". However, it will probably be a little while before I can review this proposal in detail, as our feature load for C# 10 is getting a little bit high. |
|
Tagging @333fred since he's championing the proposal. |
proposals/pattern-variables.md
Outdated
| Note: This is the expression variation of the previous case. | ||
|
|
||
| For a *negated_pattern* of the form `not pattern_operand`: | ||
| - Pattern variables declared in the *pattern_operand* **must be redeclared** inside any other *negated_pattern* in the containing pattern; permitting: |
There was a problem hiding this comment.
"... inside any other negated_pattern..."
What if there's more than one nested negated_pattern? e is not (0, var x) and not not (0, 0) #Pending
There was a problem hiding this comment.
Haven't thought this through yet. To keep things simple, we could add this at some later point if there's enough support to allow such patterns. (added to open issues)
|
|
||
| Allow variable declarations under `or` patterns and across `case` labels in a `switch` section. | ||
|
|
||
| ## Motivation |
There was a problem hiding this comment.
I'd add some more practical (less abstract) motivating examples.
Looking that the roslyn codebase, we often have a switch expression just to get some value out of different kinds of bound nodes. Many can be found just by searching for "node switch".
But I have to say looking at that search result, most of them don't look like they would benefit from this feature (either they use when clauses for different cases, or they call different property/method overloads in the different cases).
Championed issue: #4018
Prototype: dotnet/roslyn@main...alrz:pattern-variables
Proposal: Rendered