Named record pattern

[Brian Goetz]

Gavin reminded me that we are not finalizing patterns in switch in 19 
(hard to keep track, sometimes), so we have a little bit of time to 
figure out what we want here.

One thing that is potentially confusing is that patterns work indirectly 
in a number of ways.  For example, if we have a declared deconstruction 
pattern for Point, you can't *invoke* it as you can a method; the 
language runtime invokes it on your behalf under the right situations.  
(In this way, a deconstructor is a little like a static initializer; it 
is a body of code that you declare, but you can't invoke it directly, 
the runtime invokes it for you at the right time, and that's fine.)

I had always imagined the relationship with locals being similar; a 
pattern causes a local to be injected into certain scopes, but the 
pattern itself is not a local variable declaration.  Obviously there is 
more than one way to interpret this, so we should make a more deliberate 
decision.

As a confounding example that suggests that pattern variables are not 
"just locals", in the past we talked about various forms of "merging":

     if (t instanceof Box(String s) || t instanceof Bag(String s)) { ... }

or

     case Box(String s):
     case Bag(String s):
         common-code;

If pattern variables could be annotated, then the language would be in 
the position of deciding what happens with

     case Box(@Foo(1) String s):
     case Bag(@Foo(2) String s):

(This is the "annotation merging" problem, which is why annotations are 
not inherited in the first place.)

I don't have an answer here, but I'm going to think about the various 
issues and try to capture them in more detail before proposing an answer.


On 5/31/2022 10:49 AM, Brian Goetz wrote:
>
>
>> Erm... I actually thought that it was your idea to allow the 'final'
>> modifier on patterns. This change was introduced in Java 16 (when
>> patterns for instanceof were finalized). Here's the initial e-mail
>> from you (item 2):
>> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-August/002433.html 
>>
>
> That mail is exactly the discussion point I was thinking of.  But I 
> never said that there should be a way to declare them as final at 
> all!  I said it was a mistake to have made them automatically final, 
> and that patterns should introduce ordinary mutable locals.  I wasn't 
> suggesting an option, just that we'd picked the wrong default (and 
> created a new category of complexity in the process.)
>
> But, its an honest leap from there to "well of course me must have 
> meant you could declare them final."  But had this been explicitly 
> raised, I would have not been in favor of this option, for two reasons:
>
>  - The conversation we are having now -- it was clear that eventually, 
> some more complex pattern would introduce variables in a way such that 
> there was not an obvious "local variable" declaration, and that we 
> would eventually be having a "for consistency" discussion;
>
>  - The value of being able to declare these things final is almost 
> zero; the only reason we are having this conversation at all is "for 
> consistency" with local variables.  But if someone said "should we add 
> a feature to let you make pattern variables final", the "meh" would 
> have been deafening.
>
>>>> instanceof @Cartesian Point p'. It looks like I cannot do the same in
>>>> the second case, which is another asymmetry.
>>> We definitely intended to not allow declaration annotations.
>> But they are allowed for type test patterns, since Java 16.
>
> Yeah, we've got a problem.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220531/4abb7e4e/attachment-0001.htm>