If we rewind a bit, for a case inside a switch, it makes sense to creates new
bindings ...
For an instanceof, again we want bindings ...
Now for an assignment, this is far less clear for me, that we do not want users
to be able to choose if they want fresh new local variables or reuse existing
ones (i do not think that mixing both should be supported).
I think you are over-indexing on the shorthand name given to this feature.
When we write
String s = f()
we colloquially think of this as "assignment", but technically the name
of this is "local variable declaration with initializer" (LVDI).
And, look closely at this LVDI usage: is it _really_ a LVDI, or is it a
type pattern being unconditionally matched to the expression `f()`? The
answer is: IT DOESN'T MATTER! The two have exactly the same semantics.
This is not an accident; exhaustive patterns are a strict generalization
of LVDI. (There are some minor corner cases that can be addressed with
small cleanups in JLS Ch5.)
We could find a more accurate name than "Pattern Assignment", but my
worry is that this would obfuscate the very real similarity between LVDI
and pattern assignment.
And we have definitely discussed and ruled out "use any old mutable
variable as a nested pattern", and I don't see any reason to reopen that
question just because the word "assignment" is being used here.
By piggybacking on patterns, we are restricting ourselves to think in terms of
patterns and not more broadly in terms of de-structuring/multiple assignments.
I think you have this backwards. Patterns, specifically
record/deconstruction patterns, _are_ Java's notion of destructuring.
Just as records are our tuples, and functional interfaces are our
function types. Just as we are not adding tuples or structural function
types, it would be a self-inflicted wound to add some sort of
destructuring that does not run through pattern matching.
Asking the question differently, apart from the fact that that this feature has a name
that starts with "pattern",
do you think that re-assigning local variables is something that should be
considered for this feature ?
I have two answers to that question.
1. It makes no sense to think of this as part of _this feature_,
because this feature is built on pattern matching. If you want that,
then you are asking for it as part of pattern matching in general, where
you can turn a mutable variable into a pattern somehow.
2. I think we very much *do not want* pattern matching to be able to
mutate existing variables, for multiple reasons. This was already well
covered the first time around.
Short answer; absolutely not.
