Hi Remi,
I know that Brian has already replied, but just to a couple of your points:
>
> The traditional approach for guards cleanly separate the pattern part from
> the expression part
> case Rectangle(Point x, Point y) if x > 0 && y > 0
> which makes far more sense IMO.
>
> The current proposal allows
> case Rectangle(Point x & true(x > 0), Point y & true(y > 0))
> which is IMO far least readable because the clean separation between the
> patterns and the expressions is missing.
Well it is, but that’s because you’ve written it in such a way. You could also
have written it:
case Rectangle(Point x, Point y) & true(x > 0 && y > 0)
which isn’t so different from the guards solution.
>
> There is also a mismatch in term of evaluation, an expression is evaluated
> from left to right, for a pattern, you have bindings and bindings are all
> populated at the same time by a deconstructor, this may cause issue, by
> example, this is legal in term of execution
> case Rectangle(Point x & true(x > 0 && y > 0), Point y)
> because at the point where the pattern true(...) is evaluated, the Rectangle
> has already been destructured, obviously, we can ban this kind of patterns to
> try to conserve the left to right evaluation but the it will still leak in a
> debugger, you have access to the value of 'y' before the expression inside
> true() is called.
As Brian has pointed out, this pattern is actually ill-formed, as the `y` is
not in scope in the guard pattern…
But thanks for the feedback. There are two issues here: expressivity and
syntax. With increased expressivity, of course you get more ways to write
difficult-to-understand code. Sometimes this is important enough for us to
reject expressivity, but mostly not. Syntax is, on the other hand, everyone’s
favourite subject :-) We could use pretty much any symbol as a pattern
operator. Your experience as an educator will certainly be very useful for us
to help determine the best choice if we go down this path - do you have any
suggestions?
Cheers,
Gavin
PS: I know you left this as a red flag, but just to say that I don’t recognise
this mission statement :-)
>
> * Java do not invent things, it merely stole ideas from the other and make
> them its own in a coherent way
