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