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.r...@oracle.com<mailto:john.r.r...@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
