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, [email protected] wrote: > > > > De: "Brian Goetz" <[email protected]> > À: "Remi Forax" <[email protected]> > Cc: "valhalla-spec-experts" <[email protected]> > 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
