Named record pattern
Brian Goetz
brian.goetz at oracle.com
Tue May 31 16:12:06 UTC 2022
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>
More information about the amber-spec-experts
mailing list