looking for FAQ on interconversion of IntFoo and Foo (original) (raw)

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 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 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 > +{ > + /** Returns the result of {@code getAsInt}, boxed. */ > + // in my dreams, this would allows IntSupplier to convert to Supplier > + public default Integer get() { return getAsInt(); } > > /** > * Returns an {@code int} value. > >

More information about the lambda-dev mailing list