Towards member patterns

[Brian Goetz]

>
>      - We basically agree that at the use site, we have all the
>     qualification modes we have with methods { constructor qualified
>     with package, static member qualified with type, instance member
>     qualified with receiver } , and possibly, an additional mode of
>     "instance qualified by type" 
>
>
> for me the special mode is more 'instance member qualified with 
> receiver' but yes,

I think you'll find once you start writing code with it that the 
receiver-qualified version is more common than you think.  And, if we 
only could have one, it has to be the receiver-qualified one, since you 
can get to the "unbound" version by specifying the receiver explicitly 
(use the match candidate as an explicit receiver), but you can't go the 
other way -- if all you have is unbound, you can't do regular 
expressions, you can't do type classes, you can't do anything virtual 
where the pattern operates on something other than itself.  So 
receiver-qualified is the "primitive" and the other is a convenience 
syntax that we can layer on top of it if we need.

>
>
>      - The details of the last one are not fully worked out, that's fine
>      - The details of exhaustiveness are not fully worked out, that's fine
>
>     Is that about right?
>
> yes,
>
> and there is also how to send parameters to the pattern method (and if 
> this is something we should support) that can be added to that list.
>

This one is interesting.  I was convinced at first we needed it, but I 
now think we can do without it (in this form), and we can get the effect 
of it in a more organic way.

In any case, glad that we're on the same page.  More docs coming.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240126/ba158712/attachment-0001.htm>