Switch labels (null again), some tweaking

[Maurizio Cimadamore]

On 28/04/2021 00:44, Remi Forax wrote:
>
>
> ------------------------------------------------------------------------
>
>     *De: *"Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>     *À: *"Brian Goetz" <brian.goetz at oracle.com>, "amber-spec-experts"
>     <amber-spec-experts at openjdk.java.net>
>     *Envoyé: *Mardi 27 Avril 2021 16:23:20
>     *Objet: *Re: Switch labels (null again), some tweaking
>
>
>     On 23/04/2021 16:38, Brian Goetz wrote:
>
>         So, I think the "a switch only accepts null if the letters
>         n-u-l-l are present", while a comforting move in the short
>         term, buys us relatively little, and dulls our pain receptors
>         which in turn makes it take way longer to learn how patterns
>         really work.  I think we should go back to:
>
>          - A switch accepts null if (a) one of the case labels is
>         `null` or (b) the switch has a total pattern (which must
>         always be the last case.) 
>
>     The proposal seems ok; it does nothing for the problem I'm
>     concerned about (e.g. type of the target expression changing and
>     influencing the totality analysis at a distance) - but that was
>     not address by the previous proposal either (as you say in your
>     email, admittedly, I was reading too much into your proposal).
>
>
> At least, if you want a total type, you can make it explicit using
>   case var x
> which is always total whatever the type switched upon.
>
> So you have two tools to avoid influence at distance in the totality 
> analysis,
> - for a switch where you can enumerate all the values enums, sealed 
> type (boolean should be in that category too IMO, but we did not agree 
> on that), if you list all the possible cases, a total case is not 
> required.

Without changes to switch, there is nothing which would break if a "new 
case" is added (to the enum, or to the sealed hierarchy). So, listing 
"all possible cases" relies on the assumption that you know what "all 
cases" are. And right now there's no way to declaratively say: this 
switch (statement) is gonna cover them all. Brian answer goes a bit in 
that direction, which is good, for the outermost layer (but the problem 
still exists somewhat at the nested level).


> - use "var" so the total case is explicit,  "case var x", "case 
> Foo(var x)", etc
Sure - this is a good solution. One minor annoying thing is that we 
started from a position where we said "var is just for inference" and 
now we're back in a place where, while  var is still, conceptually at 
least, about inference, developers will also be using it for totality 
(as inference guarantees that you are always 100% covered).
>
>     Stepping back - my general feeling on this topic is that the
>     audience in this mailing list have a very intimate knowledge of
>     what a "total pattern" is, to the point that they are comfortable
>     building on top of this definition to e.g. define null behavior of
>     patterns. I'm a little afraid that the finer detail of totality
>     might be lost on the average Joe developer: totality is a much
>     more slippery concept than it seems. Sure, there is one obvious
>     way to make your pattern total: if the target expression has type
>     E, then add a type test pattern whose type is also E. That seems
>     easy enough. Except that, the type of E will not always be that
>     manifest in user code (e.g. might be the result of what javac
>     happens to infer on Tuesdays). And, if you mix this with sealed
>     classes, it might be possible for a switch to go from total to
>     non-total, as new permitted subtypes are added to a sealed
>     hierarchy. These might all be all corner cases - but I think it's
>     this complexity which contributes to my "isn't this all too
>     subtle?" feeling.
>
>     Obviously I'm well aware that nearly every path has been explored,
>     and no silver bullet seems to be laying around, so... this might
>     just be the best we can offer, and that's ok.
>
>
> We tried to have a way to signal that a pattern is total or not, by 
> example, using a keyword, like total or default, but it did not work 
> well when a pattern is partially total like "case Foo(true, var x)"

Yep - I'm aware of the various roads not taken - I'm not suggesting that 
there's some shiny great solution which is better than what is being 
proposed; I just wanted to air my concerns about the complexity of the 
programming model implied in this proposal. In other cases (DA/DU, 
scoping of pattern variables and, to a certain degree type inference, 
esp. after Java 8) the rules are mind-blowingly complex, but developers 
can form an intuitive notion of how these things work, and trust the 
compiler to do the right thing - e.g. these features, despite their 
complexity are mostly out of your face, and when the compiler barks, the 
user will have some idea of what went wrong (whooops, uninitialized 
final variable here!). Totality analysis is not as complex as some of 
the features mentioned above - but it is something that users will have 
to think about in the back of their minds, when reasoning about how 
their pattern switches work.

Maurizio

>
>
>     Cheers
>     Maurizio
>
>
> Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210428/d51e5028/attachment-0001.htm>