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
(This is basically reopening #2181 as a new feature.)
Allow <expression> 'case' <pattern> ('when' <expression>)? as an expression which:
Evaluates to a bool result.
Introduces variables that are available on the true path out of that bool, if it occurs in a condition position.
Since patterns look like expressions, and can end in ?, and the start and end of case...when are expressions, we must know where a case expression ends.
That means it must likely be a production of <expression>, which means it cannot be combined with any operators without being parenthesized, and it will have to be delimited in some way in all uses.
(Not absolutely sure about the placement in the grammar, but likely close to this. At least you definitely don't want an unparenthesized case-expression as the value or when clause of another case-expression.)
If the pattern introduces variables, then those variables are in scope in the when clause as usual.
Further, if the case-expression (or parenthesized expression, or !-negated expression) is use in a condition position, which means any position where its value directly affects control flow (has a "true" branch and a "false" branch), then the variables are available on the true path, until the end of the current constructor/block.
(This is not intended to be something new, it's exactly the same continuation where a promoting test would promote, except that the variables are also limited to the scope they are declared in.)
Example:
var x = input caseBox(:var value) ? value : input;
(I know this is bad style. It does show that a variable is available in the rest of the block, as long as it's dominated by the true test.)
If a case expression is used as the condition of an if statement/element, a for statement/element or a while statement, then the variables are available in the body (if that's the true-branch), but not outside of the satement. It is as if the if/loop structure introduces a scope block containing the condition itself, and then the body is another nested scope.
This is consistent with how if/case works today, but this allows doing multiple independent cases:
if ((ex caseFoo(:var x) when x >0) && (ex2 caseBar(:var y) when y >0)) {
both `x` and `y` in scope.
}
The text was updated successfully, but these errors were encountered:
lrhn
added
feature
Proposed language feature that solves one or more problems
patterns
Issues related to pattern matching.
labels
Apr 30, 2025
Feels pretty subtle and unintuitive to me. I do grant that it effectively offers a solution for #2537. I just wonder if it's too subtle and we should have a more explicit guard-like statement.
(This is basically reopening #2181 as a new feature.)
Allow
<expression> 'case' <pattern> ('when' <expression>)?
as an expression which:bool
result.true
path out of thatbool
, if it occurs in a condition position.Since patterns look like expressions, and can end in
?
, and the start and end ofcase...when
are expressions, we must know where a case expression ends.That means it must likely be a production of
<expression>
, which means it cannot be combined with any operators without being parenthesized, and it will have to be delimited in some way in all uses.Proposed:
(Not absolutely sure about the placement in the grammar, but likely close to this. At least you definitely don't want an unparenthesized case-expression as the value or when clause of another case-expression.)
If the pattern introduces variables, then those variables are in scope in the
when
clause as usual.Further, if the case-expression (or parenthesized expression, or
!
-negated expression) is use in a condition position, which means any position where its value directly affects control flow (has a "true" branch and a "false" branch), then the variables are available on the true path, until the end of the current constructor/block.(This is not intended to be something new, it's exactly the same continuation where a promoting test would promote, except that the variables are also limited to the scope they are declared in.)
Example:
and
(I know this is bad style. It does show that a variable is available in the rest of the block, as long as it's dominated by the
true
test.)If a
case
expression is used as the condition of anif
statement/element, afor
statement/element or awhile
statement, then the variables are available in the body (if that's the true-branch), but not outside of the satement. It is as if theif
/loop structure introduces a scope block containing the condition itself, and then the body is another nested scope.This is consistent with how
if
/case
works today, but this allows doing multiple independent cases:The text was updated successfully, but these errors were encountered: