looking for FAQ on interconversion of IntFoo and Foo<Integer>

[Remi Forax]

On 04/17/2013 10:08 AM, Ali Ebrahimi wrote:
> Hi,
> does not IntSupplier  specialize Supplier? if yes, should not 
> IntSupplier wins over Supplier. what is most specific candidate?
>
> Ali Ebrahimi

yes exactly, and it wins without IntSupplier having to extends Supplier.

Let's take an example:
   public static <T> T gen(Supplier<? extends T> supplier) {
     System.out.println("generic");
     return supplier.get();
   }

   public static int gen(IntSupplier supplier) {
     System.out.println("specialized");
     return supplier.getAsInt();
   }

   public static void main(String[] args) {
     System.out.println(gen(() -> 3));
   }

it will print "specialized" even if IntSupplier doesn't inherits from 
Supplier,

gen is called with () -> int, so gen(Supplier) and gen(IntSupplier) can 
be called,
neither is more specific than the other because there is not subtyping 
relationship between Supplier and IntSupplier
but because () -> 3 is a lambda and Supplier and IntSupplier are 
function interfaces,
the compiler will see Supplier and IntSupplier as structural type,
i.e. the compiler will see Supplier as <T> () -> T and IntSupplier as () 
-> int,
and because () -> int is more specific, gen(IntSupplier) will be chosen 
are most specific method.

cheers,
Rémi

>
>
> On Tue, Apr 16, 2013 at 12:57 PM, Remi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     On 04/16/2013 09:01 AM, John Rose wrote:
>     > Where is the standard place to find the design discussion for
>     primitive-type specializations of the new interfaces (functions,
>     producers, consumers, optionals...)?
>     >
>     > In particular, will users be able to ignore higher-order
>     functions of unboxed values and later adjust code locally for
>     efficiency?
>     >
>     > If so, are there conversion operators that correspond to
>     auto-box and auto-unbox of non-functional, which can be used to
>     make adjustments at the boundaries?
>
>      From the compiler point of view, in a lambda conversion Integer as is
>     not a boxed int,
>     so there is no such auto-boxing. Said differently a Stream of Integers
>     and a Stream of ints are not the same object.
>
>     >
>     > Finally (and this is what prompted me to ask) why not make
>     IntSupplier or OptionalInt be sub-interfaces of the
>     reference-bearing ones, with autoboxing around the edges (see below)?
>
>     At some point in the past, IntSupplier was a subtype of Supplier
>     but it
>     doesn't play well with type inference
>     and method resolution in the compiler
>     Supplier or IntSupplier because they are functional interface are seen
>     by the compiler as structural types
>     and mixing structural types and classical subtyping relationship has
>     some hairy interactions.
>
>     >
>     > Since this is probably a rehash of past discussions, I'm looking
>     to be pointed at some sort of Email thread or even (!) a wiki page.
>     >
>     > Best,
>     > — John
>
>     cheers,
>     Rémi
>
>     >
>     > P.S. It looks like this sort of stuff was in the repo at first
>     and then was yanked recently.
>     >
>     > diff --git
>     a/src/share/classes/java/util/function/IntSupplier.java
>     b/src/share/classes/java/util/function/IntSupplier.java
>     > --- a/src/share/classes/java/util/function/IntSupplier.java
>     > +++ b/src/share/classes/java/util/function/IntSupplier.java
>     > @@ -32,7 +32,12 @@
>     >   * @since 1.8
>     >   */
>     > @FunctionalInterface
>     > -public interface IntSupplier {
>     > +public interface IntSupplier
>     > +    extends Supplier<Integer>
>     > +{
>     > +    /** Returns the result of {@code getAsInt}, boxed. */
>     > +    // in my dreams, this would allows IntSupplier to convert
>     to Supplier<Integer>
>     > +    public default Integer get() { return getAsInt(); }
>     >
>     >      /**
>     >       * Returns an {@code int} value.
>     >
>     >
>
>
>