[patterns] reconsidering how the created variable name binds

[John Rose]

On Dec 28, 2019, at 2:16 PM, Reinier Zwitserloot <reinier at zwitserloot.com> wrote:
> 
>> 
>> ... I’m pretty sure the core designers have anticipated all the relevant
>> examples already.
>> 
> 
> Tagir's example with the DA rules and the compile time constant was
> anticipated?

I don’t think so, but I happen to know that the “throw stuff” example
I proposed *was* anticipated.  My claim applies to “all relevant” not
“all possible” examples.  You can falsify my claim it by proposing a
really viciously bad use case that makes someone like Brian say,
“gee thanks, I didn’t think of that, this is a good reason to reduce
expressiveness”.  It’s can happen, but I think in this case the ground
is pretty well covered.

You are right on target when you note that these adjustments are
on the table because of the odd innovation with pattern matches,
which allows new variable bindings to “pop out the side” of an
expression, instead of being properly introduced by a nice solid
declaration.  We are accepting this new kind of “surprise binding”
because it seems to be intrinsic to the design of pattern matching,
where the multiple outputs of a pattern expression appear syntactically
in the position of inputs to an analogous construction expression.
If you accept that patterns are (in part) deconstruction expressions,
you end up with the requirement that their outputs come from
their “insides”, which is where the *inputs* naturally occur in
the arrow-reversed construction expressions.

Given all that, the problem becomes managing the surprise factor
of the “pop-out names”.  The job of the language is to make such
management *possible* and even *inexpensive*, but it’s usually the
job of some other tool to *enforce* or *encourage* healthy practices
(the “broccoli” I was referring to earlier).

Restricting the places where such pattern expressions occur, and/or
(further) restricting the scope of the names that pop out, would
contract the language without definitively solving the problem of
puzzlers.  And complex, discriminating, puzzler-averting rules
typically *add* puzzlers, like “why doesn’t my code compile?”

— John

P.S. You have twice urged that the example of “for (int v; )” be
somehow transferred to “if (x instanceof String v)”, but have supplied
neither precise rules nor rationale for doing such a thing.  That’s what I
mean when I say that your proposal is incomplete.  Allowing the moral
equivalent of “if (int v; …)” has a pleasing symmetry in principle but
I personally don’t think it shows much promise, after you pull on that
thread for a while.  If we did such a thing, I think we’d want to examine
all of our structured control flow statements for similar extensions, and
that would lead, probably, towards some sort of distinct let-statement,
rather than adding let-bindings to all statements.  Good old “for (int v;)”
is a one-off, I think.