Missing substitution in 18.3?
Stephan Herrmann
stephan.herrmann at berlin.de
Tue Dec 17 07:27:18 PST 2013
Here's an example:
import java.util.*;
import java.util.stream.*;
public class X {
public void test() {
List<Person> roster = new ArrayList<>();
Map<String, Person> map =
roster
.stream()
.collect(
Collectors.toMap(
p -> p.getLast(),
p -> p
));
}
}
class Person {
public String getLast() { return null; }
}
Appling 18.5.2 for toMap has
R = Collector<T,?,Map<K,U>>
A1 = T
Thus T goes into this capture bound:
Collector<β1, β2, β3> = capture (Collector<T,?,Map<K,U>>)
In the implementation β1 print here as T#5.
In 18.3 incorporating the capture bounds has
A1 = T
T is not a wildcard, hence the bound T#5 = T is added.
During incorporation we combine the bounds
T#5 :> Person (reduced from ⟨G<β1, ..., βn> → S⟩)
T#5 = T
creating the constraint ⟨T :> Person⟩, which reduces to FALSE,
but we should find a solution.
At some point the type variables T,K,U of toMap must be
substituted with their inference variables, but neither 18.5.2
nor 18.3 say so, or am I missing anything?
best,
Stephan
On 12/17/2013 01:13 AM, Dan Smith wrote:
> The substitution should not be applied to Ai -- it's for the declared bounds, not the (use-site) type arguments.
>
> Can you provide an example so I can explore whether there's something wrong with 18.5.2?
>
> —Dan
>
> On Dec 9, 2013, at 6:21 PM, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:
>
>> I'm looking at a complex example where inference fails
>> (contrary to javac behavior).
>> The most likely problem is in 18.3., sedond list, bullet 5:
>>
>> "If Ai is not a wildcard, the bound αi = Ai is immediately implied."
>>
>> I believe sustitution θ must be applied to Ai, here!
>> (prefix or postfix as you like :) )
>> Alternatively, there could be s.t. wrong with how the capture bound
>> was first created in 18.5.2 (rhs here has no substitution either).
>> The point is we are leaking type variables into the inference,
>> for which inference variables have been defined -> FAIL.
>>
>> Do you agree?
>> Stephan
>
More information about the lambda-spec-experts
mailing list