Named record pattern

[Brian Goetz]

> 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.

Our first (wrong) inclination was to treat pattern variables as a whole 
separate thing from locals.  This, in turn, led to further gratuitous 
divergence such as the treatment of finality.

The big difference between a pattern variable and a local is their 
scope.  We have carefully defined the scope of a pattern variable to be 
exactly those places where it would be DA.

> So we can merge bindings and as a result have one local variable to be 
> used in the body.

This only works if we are cagy about *where* the declaration is.  If we 
say that in

     case Foo(int x), Bar(int x):

that both `int x` are separate declarations, then we've foreclosed on 
this avenue.  If instead we let patterns "summon locals into existence", 
then if they sing in proper harmony, then two patterns can summon the 
same variable.  While we're not 100% dedicated to this, ruling it out 
also seems questionable.

> 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) { }

This is an annotation *on the record component*.  There are rules for 
how annotations flow from components to other API facets (fields, ctor 
arguments, accessor methods, etc.)

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

The question is: what is being annotated here?  The pattern itself, the 
binding variable, or the type-use of String?  Annotations on patterns 
would be a little like annotations on record components; they may flow 
through to other things, but the pattern and the binding are separate.

> 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.

This is awfully handwavy; I'd prefer to make these decisions on some 
other basis than "it seems to arrive at the answer I want in this 
case."  In fact, everything about this argument is making me think 
annotations on pattern variables is a serious mistake.

> 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.

I don't think we want to touch this with a ten foot pole.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220601/c7bdb08d/attachment-0001.htm>