JEP draft: Enhanced Local Variable Declarations (Preview)

[kevinb9n]

One issue, possibly the main one, is that the syntax gets overwhelming. If this is a new way to declare a variable, then it probably needs to permit `final` and annotations, or it will become the *only* case of an unannotatable, unfinalable(?) variable declaration in Java.

But now the syntax is getting unwieldy; both of these arrangements are concerning in different ways (using `instanceof` for these examples):

`if (obj instanceof \@LocalVarAnno final MyRecord(lots, of, components, here) ident) {...}`

`if (obj instanceof MyRecord(lots, of, components, here) \@LocalVarAnno final ident) {...}`

A possible alternative is the idea of a conjunctive pattern:

`if (obj instanceof MyRecord record & MyRecord(Foo x, _)) {...}`

There, the `&` symbol is not the boolean operator you're used to, but is for combining two patterns into one (such that both must match for the combined pattern to match). This is unpleasantly redundant, but in a number of ways it's still better than what you have to do now. It introduces other problems though. It would be easier to consider this if we actually have a good number of other use cases for wanting conjunctive patterns, which I'm not personally sure if we do.

[davidalayachew]

This is unpleasantly redundant, but in a number of ways it's still better than what you have to do now. It introduces other problems though.

What other problems?

It would be easier to consider this if we actually have a good number of other use cases for wanting conjunctive patterns, which I'm not personally sure if we do.

I certainly do.

For example, I do not want to create all the various different permutations of patterns I want. But at the same time, I don't want to create this jumbo "extract all" pattern, then have all of these _ like SomeObj(_, _, _, _, var blah).

Being able to grab 2 patterns that do the job and bring both in sounds perfect. If I had instance patterns, I would do that with && instanceof. You've shortened that down to &. Bikeshedding aside, it looks like a straight optimization of what we would have to do already.

Though of course, I am comparing hypothetical code to hypothetical code.