Relaxed assignment conversions for sealed types

[Maurizio Cimadamore]

On 24/11/2020 14:45, Remi Forax wrote:
>
>
> ------------------------------------------------------------------------
>
>     *De: *"Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>     *À: *"Brian Goetz" <brian.goetz at oracle.com>, "Tagir Valeev"
>     <amaembo at gmail.com>
>     *Cc: *"amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>     *Envoyé: *Mardi 24 Novembre 2020 15:10:35
>     *Objet: *Re: Relaxed assignment conversions for sealed types
>
>
>     On 31/10/2020 23:30, Brian Goetz wrote:
>
>
>
>             On Oct 25, 2020, at 10:06 AM, Brian Goetz
>             <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>>
>             wrote:
>
>             To make it clear that I'm not talking about the annoyance
>             of typing the cast, let's pretend I'm suggesting to write
>             it like this:
>
>                 BarImpl bi = (__static BarImpl) b;
>
>
>         Pulling on this string some more — I think there’s a
>         connection between this feature and total statement switches.
>          We’ve been looking for a way to make statement switches
>         total, and here, what we’re looking for is a way to make
>         _casts_ total.  Which suggests this is one feature, not two.
>          So perhaps:
>
>             switch-total (x) { … }  // a switch, but with added bonus
>         totality checking
>
>             BarImpl b = (total BarImpl) bar  // a cast, but with added
>         bonus totality checking
>
>     I agree the latter is a common enough problem when writing
>     implementation code where you have a sealed hierarchy and you know
>     there's only one impl (Foreign API has this all over the place).
>
>
> You think that not typechecking that BarImpl is the sole 
> implementation of Bar everytime you write a cast is a problem ?
> I don't know for the Foreign API, but having a static helper method 
> that takes a BarImpl and returns a Bar is not enough ?
I'm saying that it's (in my humble experience) a common enough pattern 
that I've seen often enough, so what Brian is proposing doesn't seem 
completely crazy to me - e.g. having some more 1st class support in the 
language for this sort of stuff can be a good thing.
>
>   BarImpl impl(Bar bar) {
>     return switch(bar) { case BarImpl impl -> impl; };
>   }
>
> Or am i missing something ?
See first-class :-) Sure, there are other ways to get there.
>
>     To throw in the mix - how is some kind of pattern match assignment
>     (we referred to as a "let expression" in some of the earlier docs
>     [1]) would change the picture here? In other words, maybe it's
>     overloading `=` which is at odds here, and we need to make it more
>     explicit that this is more akin to an extraction/match?
>
>
> The match operator (as in let ... match), is more or less what C# as 
> done by using switch as an operator,
>   BarImpl impl(Bar bar) {
>     return bar switch { case BarImpl impl -> impl; };
>   }
>
> It's still a possible syntax for total-switch.
> Anyway, it doesn't answer to your question, it seems you want 
> something in the middle in between a cast and a switch, let impl = bar;

I think all your references to switch expression reinforce my feeling 
that having a pattern-matching based way to declare local variables (as 
the document I linked in [1] shows with its __let construct) might be 
one way to skin this cat.

Maurizio

>
>
>     Maurizio
>
>
> Rémi
>
>     [1] -
>     https://cr.openjdk.java.net/~briangoetz/amber/pattern-semantics.html
>
>
>         Obviously we can use another word besides `total`, but it’s a
>         pretty good straw man.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20201124/e3127644/attachment.htm>