Relaxed assignment conversions for sealed types

[Remi Forax]

----- Mail original -----
> De: "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é: Dimanche 25 Octobre 2020 15:06:42
> Objet: Re: Relaxed assignment conversions for sealed types

[...]

> 
> On to Remi's comments:
> 
>> If we have a rule that allows semless conversions between the super reference
>> type and primitive object type,
>> the pair super reference type/primitive object type  will behave more or less
>> like the auto-boxing rules between an Integer and an int.
> 
> That's exactly how I think it's going to work; we generalize
> boxing/unboxing to "value widening/narrowing" conversions, with the
> exact same semantics, and apply to all value/ref projections of
> inlines.  This neatly flows into rules like overload selection, where
> candidates without conversion are preferred to candidates with
> conversion.  No new rules to learn; just more uniform boxing. (Reminder:
> this is the Amber list, so take disagreements with this statement to the
> Valhalla list.)

I don't disagree, i mention Valhalla primitive object type on this list to provide context to Tagir.

> 
>> One issue I see with this proposal, and the original one by Brian, the relation
>> is asymetric,
>> MyFooImpl to MyFoo is subtyping but MyFoo to MyFooImpl is unboxing (so not the
>> same pass when finding the most specific method), so it doesn't work fully like
>> Integer and int.
>> And i've used unboxing because it's already an existing rule, but maybe it's a
>> new kind of conversion that will require us to carefully think about
> 
> Mucking up the declaration site for this seems unnecessary, and also
> limits the usefulness of it.  (As proposed, this can work when you have
> multiple subtypes that implement a common interface.)

yep, using the declaration site is more restrictive but because it's a handshake if someone add a new permitted type, the code will not compile at the declaration of the sealed type and not somewhere else in the application.

>  But, the part of this that is worth discussing is that yes, this could be a _conversion_
> rather than assignability.  The effect of this would mostly show up in
> overload selection (where the strongly applicable options are preferred
> over the loosely ones) and type inference. Its a possibility, but I'm
> not sure it really buys much, and doesn't really address Tagir's "too
> magic" concerns.  (If anything, conversions are more magic than
> assignability.)

I've proposed boxing because i fear that if subtyping and this new conversion are at the same level, we will have trouble with inference because you can go in both direction at the same time.

Rémi