On Tue, 28 Apr 2020 at 16:10, Bob Weinand <bobw...@hotmail.com> wrote:
> I think you should first think about why the "case" needs to exists at
> all. In particular it exists to distinguish goto labels from the case
> expressions in switch. With match, match restricting statements (and thus
> goto labels) into { brackets }, it now is not necessary to do such a
> distinction and we can get rid of the extra token.
>
That may be obvious if you're used to writing parsers, but to users, the
case keyword is simply how switch statements work. Removing it just makes
the new statement look less familiar and isn't justified by the aims stated
in the RFC.
> "=>" is logical as well, we use the return value of the expressions (see
> fn() and array syntax), the colon is exclusively used for pure statement
> boundaries.
>
You've missed the context of my e-mail: I was explicitly discussing a
hypothetical syntax that *doesn't* resolve to a value, and where the colon
*is* introducing a statement not an expression.
> The comma is necessary for the expression syntax at least (consider
> match($a) { 1 => 2 + 2 + 2 => 3 } - is this now match($a) { 1 => 2, (2 +
> 2) => 3 } or match ($a) { 1 => (2 + 2), +2 => 3 } ?) You may argue to make
> it optional behind a statement block though.
Again, expressions are explicitly out of scope for this thought experiment.
As such, the result of every case is delimited either by a closing brace or
a semi-colon, and the above example is simply a syntax error.
As I've said many times now, I really like the match expression, with the
current syntax, as a pure expression. I was explicitly addressing the
question of why I think a straight-forward switch replacement would not
look the same if we weren't trying to squeeze two features into one syntax.
Regards,
--
Rowan Tommins
[IMSoP]
