Next up for patterns: type patterns in switch

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "John Rose" <john.r.rose at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 11 Août 2020 18:36:18
> Objet: Re: Next up for patterns: type patterns in switch

>> The main drawback, being total is not a __local__ property.
> 
> This is true, and we've talked about this from the beginning, but I also
> think that the fear of nonlocality here is pretty overblown. Yes, there
> are puzzlers, but they are mostly of the kind where `var` and "diamond"
> interact -- and the solution to those puzzlers is "add back some
> explicitness, so it's clear what is going on."  The solution is not
> "let's cripple var so it doesn't interact with diamond", or "let's
> outlaw the interaction of var and diamond" or "let's not do var."
> 
> We proposed using totality not because its "clever", or because it makes
> a certain pesky problem go away, but because it is the most _natural_
> way to unify the semantics of all the ways patterns are used, and this
> becomes obvious once you get to examples that actually use nested
> patterns.  I think much of the reaction to this aspect is based on
> holding on to the existing model of switch/instanceof, which are both
> very limited right now.  Once you see these as more general
> deconstruction operations, the role of totality immediately comes to the
> fore, because of the expanded range of problems we will see with
> conditional destructuring.  So I think there's a lot of "judging the new
> feature by the use cases of the old feature."  We may be reusing the
> syntax of instanceof and switch (for good reasons), but these are not
> the instanceof and switch you learned about in CS 101.  Lets not hobble
> the new feature because the old version was insufficiently ambitious.
> 
>> So this is far worst that re-organizing two cases in the switch because as a
>> user you have done something. A pattern can be total or not depending if
>> someone change the return type of the method you are switching on (this methods
>> can be in another module) or change the class hierarchy (again, the hierarchy
>> can be defined in another module), the code stay exactly the same but the
>> semantics is changed.
> 
> Sorry, but I think this is mostly FUD.  There are a zillion ways to
> leave information implicit: var, diamond, generic invocation, method
> chaining, method references (which pick an overloading), implicit
> lambdas, etc.  And there are a zillion ways to construct puzzlers from
> code that does something implicit, where the answer would be obvious if
> we wrote out the fully explicit representation.  And the same thing
> always happens when a new feature wants to join this club: "There exists
> a possible way someone could get confused by combining these ten
> features, so we must blame the last feature that came in the door!"

It's not FUD, and worst you know that there is a solution to avoid the problems of non locality of requiring the last case to be total.

This is how i see the future if we introduce the current proposed semantics.
Someone will ask on StackOverflow why a particular switch doesn't accept null (hint: the last case is not total even if it looks like it is).
Someone will answer that instead of trying to know if the last case is total or not, it should use "case var foo" because it's always total (quoting this email to get an inception like taste).
The IDEs will start to have a hint to refactor the "case TotalType foo" to "case var foo" because it solves the non locality problems making the code more future proof.

In 5 years from now, most devs that are using pattern matching will write the code as in C#.

So i propose to disallow that a case with a total pattern can use an explicit type with a nice message saying to use "case var" instead.
This will effectively fix the non locality issues of the current proposal.

> 
> So, coming back to the main goal, our job here is first to find the
> _natural_ semantics of pattern  matching.  And every path I've gone down
> tells me that totality is part of the natural semantics.  And I've not
> seen any credible arguments that suggest it is not -- just fear that,
> through interactions with other features, it might be too new, too
> complicated, too confusing, etc.  But this happens with every new
> feature!  We're used to (and have come to terms with) the OLD features
> interacting in possibly puzzling ways (e.g., var+diamond), but when a
> corner of a corner of a NEW feature threatens to do so, people declare
> "this entire new feature is broken."


yes, we are spending a lot of time one a corner of a corner case, and i agree that totality is part of the natural semantics,
but it doesn't mean we have to force users to think in term of totality.

> 
> More importantly, we want to have the right _global_ story. Proposing
> localized hacks to deal with the aspects you don't like is highly
> unlikely to bring us to the right global story.

given we are talking about a corner² case, it should play only a small part of the global story anyway.

regards,
Rémi