Infer type parameters from constraints #9455
Conversation
Co-authored-by: Jan Jones <jan.jones.cz@gmail.com>
| > - The set of *candidate types* `Uₑ` starts out as the set of all types in the set of bounds for `Xᵢ`. | ||
| > - Each bound for `Xᵢ` is examined in turn: For each exact bound U of `Xᵢ` all types `Uₑ` that are not identical to `U` are removed from the candidate set. For each lower bound `U` of `Xᵢ` all types `Uₑ` to which there is *not* an implicit conversion from `U` are removed from the candidate set. For each upper-bound U of `Xᵢ` all types `Uₑ` from which there is *not* an implicit conversion to `U` are removed from the candidate set. | ||
| > - If among the remaining candidate types `Uₑ` there is a unique type `V` to which there is an implicit conversion from all the other candidate types, then `Xᵢ` is fixed to `V` **and a lower-bound inference is performed from `V` to each of the types in `Xᵢ`'s constraints, if any**. | ||
| > - Otherwise, type inference fails. |
There was a problem hiding this comment.
I haven't thought about the full implications of this algorithm, namely the set of things that will now be inferrable, and what will remain uninferrable.
Ideally I think we'd do as much as possible here. By that I mean, a general statement that if it is theoretically possible to infer the type, we do so. In practice, I'm worried our subtyping + overload resolution rules will make this undecidable.
But it's worth digging in to the literature to figure out precisely what will fall over.
There was a problem hiding this comment.
Btw, starting w/ Algorithm W is not a bad idea.
There was a problem hiding this comment.
I've thought about this for a bit and my new thoughts are: I don't think this change is very complicated, and I'm not sure we have much to worry about.
Basically, we're not doing full type inference, we're just doing type subsitution for particular invocations. It doesn't seem like there's a lot of information that we could be missing with this algorithm.
|
Strongly in favor of this change. |
| ## Drawbacks | ||
|
|
||
| The primary concern with this proposal is that it introduces potential breaking changes in overload resolution. Code that currently compiles and calls one overload might start | ||
| calling a different overload after this feature is implemented. |
There was a problem hiding this comment.
This could likely also lead to new ambiguity errors by bringing in new candidates that aren't clearly better or worse than the one called today. Probably worth mentioning.
Adds a championed proposal for inferring type parameters from constraints.