Collapsing the requirements

[John Rose]

On Aug 5, 2019, at 4:08 AM, forax at univ-mlv.fr wrote:
> 
> 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.

I would prefer to make the inline classes work well with libraries, including generic inference, so that the companion box type is require as rarely as possible, only for instantiation.

So, List<V.Box> is required, but if you say List.of(V.default) inference should pop up to List<V.Box>, just like List.of(1) pops up to List<Integer>.

As Brian suggests, this is the sort of detail that needs to be worked out.  I’m hopeful it can work at least as well as today’s int/Integer rules.