Named record pattern

[Remi Forax]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Tagir Valeev" <amaembo at gmail.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Tuesday, May 31, 2022 6:12:06 PM
> Subject: Re: Named record pattern

> 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.
For me, there is a difference between a binding and a local variable, is that bindings are the one declared inside a pattern and a local variables is how a binding is transformed to be usable inside the boby if the pattern match. 
So we can merge bindings and as a result have one local variable to be used in the body. 

About the annotations, if we follow the data orientation principle (data is more important than code), we can have a record 
record Person(@NonNull String name) { } 

and a record pattern 
case Person(@NonNull String s) -> ... 

We want to be able to declare @NonNull in the record pattern so if the data is changed, if the component name of the record becomes nullable by example, the pattern will fail to compile. 
So i think we should allow annotations because it's a way to enforce that data are more important that code. 

As you said, annotation merging is an issue because the correct merging requires to know the semantics of the annotations and the compiler has no way to know that. 
But there is a simple solution, annotation are trees, so they can be compared structurally. Thus we can do bindings merging if the annotations are the same structurally. 

regards, 
Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220601/fe8f3efc/attachment.htm>