On 08/07/2020 12:30, Rhodri James wrote:
Any name used as a pattern is a catch-all. The only difference between "case dummy:" and "case _:" is that "_" doesn't bind to the thing being matched, but "dummy" does bind to it.
I meant catch-all as in "case _:" (or "else:"). I apologise for the lack of clarity. On 08/07/2020 17:02, Guido van Rossum wrote:
There’s one other issue where in the end we could be convinced to compromise: whether to add an `else` clause in addition to `case _`. In fact, we probably would already have added it, except for one detail: it’s unclear whether the `else` should be aligned with `case` or `match`. If we are to add this we would have to ask the Steering Council to decide for us, as the authors deadlocked on this question. Thanks for the write-up. What were the arguments in support of aligning else with case? I expect it has to be with aesthetics, but for what concerns semantics, it seems to me that "match...else", interpreted as "no match was found" would make the most sense; aligning it with case would look like the else has to do with whatever case was last. Unless both match and all cases are on the same indentation level. Here an example:
match: variable case "some constant": # ... case x if x == guard_clause: # ... else: # ... I know at least Elm indents the match variable on a separate line. On 08/07/2020 19:44, Tim Peters wrote:
One microscopic point:
... (if `.x` is unacceptable, it’s unclear why `^x` would be any better), As Python's self-appointed spokesperson for the elderly, there's one very clear difference: a leading "." is - literally - one microscopic
[Guido] point, all but invisible. A leading caret is far easier to see, on a variety of devices and using a variety of fonts. Indeed, I missed the leading dot in ".x" in your email the first two times I read that sentence.
But a caret is harder to type. So here's an off-the-wall idea: use an ellipsis. If you're still using a maximal-munch lexer, ellipsis followed by an identifier is currently a syntax error. "...x" is far easier to see than ".x', easier to type than "^x", and retains the mnemonic connection that "something is a named load pattern if and only if it has dots".
+1 on a simple dot being hard to see. Alternative idea: if we really ought to have a mark for references¹, why not use the & symbol, which already signifies something like "reference" in C(++) and Rust? ¹: I know marking "store" instead of "load" has been suggested before; I'm still on the fence on which I prefer but I would even accept marking both (with = and == respectively, for example).