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 =
                           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?


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