Funnily enough, this exact syntax was considered when pattern matching was first discussed. There was a very lengthy discussion about whether to use switch or whether to use a new keyword (like inspect), and one of the ways that was suggested in the switch case was to use square brackets instead of parens to differentiate a pattern switch from a normal switch. The support for it was even considerable, but I think the inspect folks won out in the end.
Interesting, this should have been reflected in the paper so others will be aware. In any case, this happened very early in the discussion and probably neither the requirements nor the developments were the same back then.
Here is a short proposal to re-use `switch` for Pattern Matching.
Just so I'm clear. The argument is that introducing a new facility, with new semantics, under a new token (whether inspect or match) would be bad for teachability.
So instead, you're proposing that we reuse an existing token (switch) to introduce two very different behaviors (statement vs expression, best match vs first match, fallthrough vs exactly one arm, integers vs more complex patterns, etc.), but since those different behaviors still need to be differentiated by the parser, you're proposing we do so by simply switching from parentheses to square brackets around the operand? And you're proposing that having 'switch' mean two very different things is better for teachability?
That's the issue, it is not different semantically or functionally. Sure there are nuances, but there are not two different tools that one might choose one over the other for a particular reason.
We must also consider the negatives by having two similar tools, the language already has a problem with that in many places, some of which going back to C like the many loops as an example.
It seems also that the negatives of extending switch are speculative, where the overlap with switch is objective, more or less.
From the 4 points you made, I honestly can't think of one that is a problem in day to day use, with the last two actually being a desired positive.
Last but not least, the problems of introducing a new keyword are not to be underestimated.
inspect (...) is basically guaranteed to be used as a function name in some code and will require some parsing ahead. `match` following the value will also be hard to do, especially in the case of multiple value (a, b, c, d) match.
These are problems we create for ourselves out of nowhere, quite literally. Better, there is a real reason for that, not just worries.
Std-Proposals mailing list