More Typing Problems

[Nathan Bryant]

Ming's original example had this:

DBSet<String> result = allCustomer()
         .select(#(c){c.getName()})
         .sortedByStringAscending(#(str){str});

So what you're saying is that the inferencer starts with the target type
DBSet<String> from the declaration of "result".

In this specific example at least, the inferencer could still start
there, and proceed by noticing that sortedByStringAscending returns type
DBSet<T> which is a transitive closure case. (DBSet<T> has to be the
same as the return type of select())


-----Original Message-----
From: lambda-dev-bounces at openjdk.java.net
[mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Maurizio
Cimadamore
...

Of course if you throw the expected type into the picture, the compiler 
can figure out that U is String and not Object. But in your example, the

one with the chained calls, there's no expected type (because the 
expected type refers to the chained call to 'sortedByStringAscending'). 
Which means the compiler has two options here: (i) issue an error 
because the inferencer doesn't have enough info to infer a type for c or

(ii) try to infer a 'default' type for c. We currently have choosed (ii)

since this is the way Java method type-inference work *already* - which 
means we think it's less disruptive to average Java programmers.