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

Ali Ebrahimi ali.ebrahimi1781 at gmail.com
Wed Apr 17 07:08:29 PDT 2013


Hi,
What is problem when IntSupplier inherits from Supplier?
what is result for System.out.println(gen(() -> 3));   ?


Ali Ebrahimi

On Wed, Apr 17, 2013 at 5:53 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> 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.
>>     >
>>     >
>>
>>
>>
>>
>


More information about the lambda-dev mailing list