[External] : Re: Two new draft pattern matching JEPs

Gavin Bierman gavin.bierman at oracle.com
Thu Mar 4 14:27:41 UTC 2021

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? 


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

More information about the amber-spec-experts mailing list