Type inference across method chains

[Brian Goetz]

On 3/17/2017 4:41 PM, Luke Hutchison wrote:
> 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

You may be right, but bear in mind that it *always* looks this way. You 
forgot the implicit "...that I currently know of" that needs to trail 
this sentence.  The definition of "real world" is implicitly bounded by 
"the stuff that works now", and always moves.  (Ten years ago, chaining 
was not considered a real world case at all.)

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

I know you probably don't think you're asking this, but you're basically 
asking "can you solve the problem (or try until you give up), and then 
explain what you did."  So, that's not really practical, as much as I'd 
love to have a simple answer I can pull out that fits on a page and is 
accessible to non-type-system-experts.  Suffice to say it's doable, but 
it's not trivial, and the risks are not trivial.

Also, bear in mind that "how difficult" is only one (and in reality, 
probably the least important) dimension of the problem.  "How difficult" 
corresponds to "how much will it cost Oracle", which is certainly a 
reasonable input into the decision process, but far from the only one.  
How about what incremental perceived complexity for the users would it 
create?  What damage would it do to scrutability of diagnostics?  What 
are the compatibility risks?  (Adding new constraints into type 
inference algorithms can often cause something that was previously 
solvable to become overconstrained, breaking existing code.)  What is 
the consequence for the specification?  For implementors like Eclipse 
that have to implement from the specification?  In what ways might it 
interact with other features, present or future?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170317/5f135fb3/attachment.html>