On Fri, 17 Jul 2020 at 12:28, Gustavo Carneiro <gjcarneiro@gmail.com> wrote:

On Fri, 17 Jul 2020 at 12:26, <emmanuel.coirier@caissedesdepots.fr> wrote:
Hello everyone,
(...)
But... looking at the examples, it wasn't very obvious that some
variables were catching variables and some others were matching ones.
I then read in details some rules about how to discover what is a
captured variable. But I'm not sure everybody will do this...

Zen of Python tells us that "explicit is better than implicit". I know
this is not a rule written in the stone, but I think here, it applies
very well.

I Also dislike the idea of undotted names being assigned, with not extra visual clues,

and the scenario described by Emmanuel, in the other e-mail about

people changing variables when they think they are making a match

(essentially introducing the _same_ problem that `if (SPAM = 0):` had in C

which Python used to justify assignment not being an expression for over

20 years).

So, in adding to the bikeshed color possibilities, alongside

the "x=, y=" in this first e-mail or the "_ as x, _ as y" from Gustavo,

I present the possibility of making the Walrus mandatory for capture.
Maybe it is a bit "too much typing" - (Walrus will require 5-6 keystrokes

with the surrounding spaces), but I think the final look can be pleasantly

intuitive:

match my_point:

case (x := _, y := _) | Point2d(x := _, y := _):

return Point3d(x, y, 0)

Guido said :
> We’re really looking
> for a solution that tells you when you’re looking at an individual
> case which variables are captured and which are used for
> load-and-compare.
>
> Marking up the capture variables with some sigil (e.g. $x or
> x?)
> or other markup (e.g. backticks or <x>) makes this common case ugly
> and inconsistent: it’s unpleasant to see for example
>
> case %x, %y:
> print(x, y)

Guido talk about a "sigil", which seems to be a meaningless mark only
here to help the parser understand what the dev was writing.

I propose that this "sigil" be the affectation mark : "=". Look :

z = 42
match pt:
case x=, y=, z:
print(x, y, "z == 42")

(...)

Gustavo Carneiro <gjcarneiro@gmail.com> wrote:

I kind of agree it is nicer to be more explicit. But somehow x= looks ugly. It occurred to me (and, again, apologies if already been mentioned), we might use the `as` keyword here.

The example above would become:

def make_point_3d(pt):
match pt:
case (as x, as y):
return Point3d(x, y, 0)
case (as x, as y, as z):
return Point3d(x, y, z)
case Point2d(as x, as y):
return Point3d(x, y, 0)
case Point3d(_, _, _):
return pt
case _:
raise TypeError("not a point we support")

If having "as x" as a standalone expression without anything to the left of "as" causes confusion, we could instead mandate the use of _ thus:

case (_ as x, _ as y):
return Point3d(x, y, 0)