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.
