Re: Updated State of the Specialization

[Timo Kinnunen]

The issue is that it forces users to write really really ugly code as a workaround. In Java 8 the BigList<BigInteger> specialization 







interface BigList<T> {

public void remove(BigInteger position);

public void remove(T element);

}



BigList<BigInteger> bigList;

BigInteger value;


needs to be called like this:


// calls remove(BigInteger position)

((BigList<?>) bigList).remove(value);

// calls remove(T element) with T=BigInteger

((BigList) bigList).remove((Object) value);


when it could be called like this:



// calls remove(BigInteger position)
bigList.remove((BigInteger) value);

// calls remove(T element) with T=BigInteger

bigList.remove(value);


Perhaps in Java 10 it will end up being called like this:




// calls remove(BigInteger position)
bigList.remove((BigInteger) value);

// calls remove(T element) with any T=BigInteger

bigList.remove((any BigInteger) value);


but I would prefer to reuse the existing cast-syntax instead.



-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Simon Ochsenreither
Sent: ‎Saturday‎, ‎December‎ ‎20‎, ‎2014 ‎20‎:‎08
To: valhalla-dev at openjdk.java.net





> Here the problem is about choosing between one method taking a plain int and another method taking a “valuable” int.
As mentioned, what's the issue with _not_ choosing one method when 
methods are ambiguous, just like in every other case when the compiler 
experiences an ambiguity issue? Just reject that line of code. Done.