Updated patterns-in-switch doc

[Brian Goetz]

>> with the possible temporary exception of the three primitive types not currently permitted
> I believe, there are four of them: boolean, long, double, and float

RIght.

> #2 Disallowing switch expressions inside guards
>
>> And worse if we allow switch expressions inside guards, which we shouldn't do.
> Hm... sounds like this may heavily complicate the grammar if we really
> want to prohibit switch expressions anywhere inside the guard. E.g.:
> switch (obj) {
> case Foo(int x)
>    __where process(switch(x) {case 1 -> 10;case 2 -> 20;default -> 0;}) -> ...
> }
> Should this be allowed? If yes, then there's no point to disallow
> top-level switch expressions inside guards, as nested ones are
> confusing to the same level.
> If yes, then the grammar should be updated to include tons of
> productions like ExpressionNoSwitch, MethodInvocationNoSwitch,
> ArgumentListNoSwitch, and so on.
>
> To me, adding any restrictions to expressions inside guards looks an
> arbitrary decision. If users really want to write confusing code, let
> them allow using expression switches in guards.

Let's separate out the grammar from the goal.

Embedding switch expressions has two problems here; one is the obvious 
syntactic confusion (what switch is that case a part of?), and the other 
is side-effects; switch expressions are the only expressions that can 
embed statements.  Both are a bad match for expressing guard 
conditions.  (Note that when we did switch expressions, we omitted the 
possibility that a switch expression could be a constant expression, to 
avoid their use in, say, case labels in a constant switch:

     case switch (x) { case 1 -> 3; case 2 -> 4; } -> 5;

I think that was the right call :)

As you pointed out yesterday on Twitter regarding old-style array 
declarations in record components, there are two ways to address it; 
constrain the grammar, or use a deliberately coarse grammar and then 
perform a post-parse check.  So if the answer is to constrain what you 
can put in guards, that doesn't mean we have to constrain the grammar.

The concern about side-effects (which I know we can't fully contain) 
comes from a bigger goal, one that may not have been explicitly stated: 
I want that the computation inherent in a pattern switch effectively be 
"constant", for a number of reasons.  Having side-effects in case labels 
or guards effectively undermines that. One benefit (but not the only) of 
doing this is that it is a necessary condition for encoding the entire 
switch logic in an `indy` bootstrap, so that we can dynamically 
construct a decision tree based on the characteristics of the case 
labels.  The more imperative a switch looks, the harder it is to do 
that.  (So, for example, guards should probably be restricted to 
capturing effectively-final locals.)

THe remaining constraining of side-effects will come from making only 
vague promises about when, and how often, to execute pattern bodies.  if 
we have a switch with:

     case Foo(var x) where x == 0:
     case Foo(var x) where x > 0:
     case Foo(var x):

we should be free to execute the deconstructor body early or 
just-in-time, once or three times (or more!)

> #3 Total patterns in instanceof
>
>> It is sensible because x instanceof <total pattern> is in some sense a silly question, in that it will always be true and there's a simpler way (local variable assignment) to express the same thing.
> It should be noted that local variable assignment requires the
> variable declaration which cannot be done inside the expression.

Yes, I realize that one can use pattern matching as a form of implicit 
assignment.  But if we think that is important, maybe it is better to 
try to get there more directly, rather than relying on a "trick".   The 
idiom you describe -- pulling a DU local into a broader scope -- works, 
but is less than ideal, because you don't get the perfect scoping.

> Well, we may split declaration and assignment and put the assignment
> inside the condition:
>
> Foo foo;
> if (x != null && (foo = x.doExpensiveCalculation()) != null &&
> foo.isValidResult()) {
>    use(foo);
> }
>
> But this has at least two drawbacks: necessity to specify explicit Foo
> type (var doesn't work anymore) and broadening the scope of `foo` more
> than necessary (it pollutes the namespace after `if`). In general, it
> looks asymmetrical to me that the condition can introduce variables
> only if we can express the condition on that variable with a pattern,
> but we cannot do this if we have a guard-like condition.

Here's how I would rather write that (if the status quo isn't good enough):

     if (x != null && (var foo = x.doExpensiveCalculation()) != null && 
foo.isValidResult()) { use(foo); }

That is, treat `var x = e` as a pattern match that always succeeds and 
generates one binding.