More Typing Problems

Nathan Bryant nathan.bryant at
Tue Sep 7 15:46:05 PDT 2010

Ming's original example had this:

DBSet<String> result = allCustomer()

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
[mailto:lambda-dev-bounces at] On Behalf Of Maurizio

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. 

More information about the lambda-dev mailing list