Type inference across method chains
brian.goetz at oracle.com
Fri Mar 17 21:40:46 UTC 2017
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...
More information about the compiler-dev