It behaves the same within an arrow function too; the $ => $.toString() gets implicitly returned but the switch value gets dropped. The issue is that the switch is a valid Statement and that takes priority over expressions.
This is what we get with an explicit return added, I believe via ExpressionizedStatementWithTrailingCallExpressions. Maybe we just need to check for this before regular Statements, but when there's a positive number of trailing expressions?
Similar to postfix .foo, it'd be nice to have postfix pipelines. Original motivating example from Discord:
switch @value
Value.Ace then 'A'
Value.Jack then 'J'
Value.Queen then 'Q'
Value.King then 'K'
else String @value
|> (+ @suit)
Currently this is a parse error, again because the switch parses as a Statement and that doesn't have postfixes available. But this one doesn't work with an explicit return either. Probably we need to add pipelines to ExpressionizedStatementWithTrailingCallExpressions (perhaps with a different name).
Consider:
Currently this compiles to:
It behaves the same within an arrow function too; the
$ => $.toString()
gets implicitly returned but theswitch
value gets dropped. The issue is that theswitch
is a validStatement
and that takes priority over expressions.I'd propose instead that it compiles to:
This is what we get with an explicit
return
added, I believe viaExpressionizedStatementWithTrailingCallExpressions
. Maybe we just need to check for this before regularStatement
s, but when there's a positive number of trailing expressions?Similar to postfix
.foo
, it'd be nice to have postfix pipelines. Original motivating example from Discord:Currently this is a parse error, again because the
switch
parses as aStatement
and that doesn't have postfixes available. But this one doesn't work with an explicitreturn
either. Probably we need to add pipelines toExpressionizedStatementWithTrailingCallExpressions
(perhaps with a different name).