Stream: wg-traits

Topic: inference on multiple conflicting traits in scope


Jacob Pratt (Nov 27 2019 at 06:37, on Zulip):

Hi all. Has there ever been any thought with regard to inferring the correct trait when there are multiple in scope (using the same method name but different signatures)? My initial thought was that since the list of conflicting traits is already known, it should be possible to iterate through them and choose the typechecks that works if no others typecheck.

My use case for this is really the same as any other function/method overloading. But specifically, in my rewrite of the time crate, I have the NumericalDuration and NumericalStdDurationShort traits, which vary only in return type. It would be great to be able to have them both in scope and do std::thread::sleep(5.seconds()) and have the compiler realize that only one trait in scope is capable of typechecking there. Right now, the workaround is to do std::thread::sleep(5.std_seconds()), which is...not as pretty.

Thoughts? I was thinking of writing an RFC, but not if there's zero chance of this happening.

Laurențiu Nicola (Nov 27 2019 at 07:59, on Zulip):

Wouldn't that allow for surprising breaking changes where if a crate changes the type of a method you're not calling but breaks your code because there's now ambiguity? Or is that already possible today?

Jacob Pratt (Nov 27 2019 at 08:14, on Zulip):

If I'm understanding you correctly, that would only happen if you already had two traits with the same function name in scope, which is currently always an error (without disambiguation). If you're referring to future changes, changing the function signature is a breaking change anyways.

Jacob Pratt (Dec 02 2019 at 20:52, on Zulip):

Anyone else have input on this, or should I create a pre-RFC over on internals?

Last update: Dec 12 2019 at 01:15UTC