Improved type inference for operators

I’d like to propose an improvement to the way operand types are inferred.

Currently, in an expression like x == y, type checking will fail if one of the operands’ types is omitted and there is more than one possible type. This is not optimal, because in almost all the cases where this happens, a type identical to the type on the other side is the expected choice.

My proposal is that whenever such a multiple choice occurs, instead of failing, the type checker would instead attempt to directly unify the types on both sides, give or take a reference. This would pave the way towards certain desirable additions to operands on primitive types, which up to now have been rejected because they would break inference, even though there is often just one variant that’s intuitively correct.

Would anyone be willing to mentor me in writing an RFC, as well as possibly implementing this in the compiler?

I think this is a reasonable idea, but I’d be reluctant to pursue it just now until we have a better technique for handling the interactions between coercions and type inference. In particular, we’d have to be careful about when we apply this unification, and I don’t know that there is an obvious time to do it in the system as it is today (but we’ve been talking about changes that would make that easier).

Reminds me a bit of https://github.com/rust-lang/rust/pull/40166

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.