Type inference across method chains

[Luke Hutchison]

On Fri, Mar 17, 2017 at 1:19 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> So let's not fool ourselves that this is "the last case" -- it's just "the
> next case."
> [...]
> So, with that, let's look at your example.  The cases which make people
> complain "type inference doesn't work under chaining" invariably reduce to
> the case where there is a generic method used as a receiver for a chained
> invocation, and whose generic type parameters cannot be solved directly
> from its arguments, but instead would need type information that would have
> to be back-propagated from later links in the chain (which generally
> further require information from the target type.)
>

Right, nonetheless, if this single "next case"  were solved via
bidirectional propagation of type information, rather than the current
situation where method overloading before the dot is solved before type
inference after the dot, I would argue that this would solve a large
majority of remaining real-world cases where an expression should quite
obviously typecheck (according to human judgment) but does not. It would
certainly cause streaming APIs to work significantly better with generics.
This seems to be the most obvious weakness in the current type inference
algorithm.

It is indeed not impossible.  But, as you say, it adds additional
> complexity to a type inference algorithm that has already grown quite
> complex (and which now interacts heavily with another complex mechanism,
> overload selection).  Could we take one more step, and move the corner
> cases further out to the margins, at the cost of greater complexity (and
> perhaps decreased usability)?  Yes, we could.  In Java 8, we chose to leave
> it here, which I think was a sensible choice.
>
> We might someday come back to look at this -- but right now, it seems like
> this is not the highest-return use of limited and highly specialized
> resources.
>

Can you please address in concrete terms, for this specific request only
(i.e. for back-propagation of type information before the final decision
about method overloading is made, as opposed to "for all cases" or "for the
last case") -- just how difficult solving this would be, and what the
technical limitations would be given the current type inference algorithm?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170317/eb3c10c3/attachment.html>