More Typing Problems
nathan.bryant at linkshare.com
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())
From: lambda-dev-bounces at openjdk.java.net
[mailto:lambda-dev-bounces at openjdk.java.net] 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