Collapsing the requirements

[Brian Goetz]

OK, now I see the chain of assumptions that led you to your concern.

Not sure if all those assumptions are valid, but we’re going to have to tackle them explicitly.

> On Aug 5, 2019, at 4:08 AM, forax at univ-mlv.fr wrote:
> 
> 
> 
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Lundi 5 Août 2019 04:15:16
> Objet: Re: Collapsing the requirements
> I’m not really following the concern you’re having.  
> 
> Let’s divide into two cases:
>  - Inline classes declared explicitly with their box (e.g., Optional)
>  - Inline classes declared without a box, which get an implicit box.
> 
> So let’s say you have:
> 
>     inline class Foo<T> implements Bar<T> { 
>         Foo<T> id(Foo<T> f) { return f; }
>     }
> 
> This would acquire a nested interface Foo.Box, as a super type of Foo:
> 
>        interface Box<T> extends Bar<T> {
>            Foo<T> id(Foo<T> f);
>        }
> 
> Can you outline what you see as going wrong here?  
> 
> This is breaking confinement but maybe confinement is a bad idea.
> Let me try to explain why i think confinement is a necessary evil for LW10.
> 
> if we have a public method like "id" that takes a Foo or return a Foo it means that you are providing a public API that doesn't play well with inference (because Foo can not be a type argument for T).
> Any user codes that will want to use a Stream, an Optional, List.of(), Arrays.asList(), etc will not work.
> So you are transferring the problem of generic over inline classes being not supported in LW10 from the library developer to the users of those libraries.
> 
> So the question is should we do something to help library developers to avoid them to publish public API with inline classes in their signature or do we think that library developers will discover by themselves that having an API with an inline class is the middle is not user friendly.
> 
> Rémi