Dominance in pattern matching for switch: Spec and Javac inconsistency

[John Rose]

P.S.  If a Java expression X is (for whatever reason)
compiled to an indy instruction, and that instruction
has a BSM that flips coins or bumps counters or
uses resources, then *two identical copies* of X
will not be equivalent.

(This relates to some conversation Brian and I
had about “constant expressions”, along the lines
of “how constant does a constant expression need
to be?”  One aspect of that set of problems is that
the user often expects to be able to use the value
of a constant expression in multiple places, at
least in some desugaring schemes, so it should
be clone-able without loss of information; that
lets us write the desugaring without generating
static temp variables.  But an indy-generating
expression is not clone-able, unless its BSM is
constrained somehow.)

On Sep 6, 2021, at 2:09 PM, John Rose <john.r.rose at oracle.com<mailto:john.r.rose at oracle.com>> wrote:

FTR, I approve of not even stepping onto this slippery
slope.  Doing so would seem to promise something of
value to users, a promise they’d probably feel we would
break by the draconian restrictions (with or without
complex case analysis on statically kennable expressions).

Remi, this relates to your offhand comment about guards
which are always true, as in case T x && alwaysTrue(x)
vs. case T (no guard).  Detecting always-true guards is
about the same problem (with no solution) as detecting
equivalent guards.  In particular if G1 and G2 are somehow
provably equivalent then G1==G2 is provably true and
G1!=G2 is provably false.  If G0 is provably true, then
G1 and G1&G0 are provably equivalent, and so on.

Statically, a guard should be treated as a coin flip
independent of every other expression.  (See also
my comment about guards working, in static
analysis, like existential subtypes of the guarded
type.)

— John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210906/cab6d45d/attachment-0001.htm>