Idea: Paths in method names

[ExpHP]

I feel like I would want the relative precedence for method resolution to be defined explicitly somewhere, and probably on a method-by-method basis

I’m not sure what such laser precision would buy us. The public dependency graph-based ordering is simply intended to minimize unexpected breaking changes due to the addition of a trait method.

Let’s say that itertools::Itertools and std::iter::Iterator had a method named foo. There are two ways this could come about. Either:

• (a) std had it first. When the author of itertools adds it, they are surely aware of the existing method in std, and must be acutely aware that this could be a breaking change for downstream code.

• (b) itertools had it first. The author could not have foreseen its inclusion in std, and std cannot afford to stop adding features just because itertools exists. But there are crates out there which use Itertools::foo, and these should continue to use it. (this is why the public dependency-based ordering prefers Itertools)

  If a downstream crate wants to switch to std’s foo, they can achieve this (abeit verbosely) by writing their own extension trait that calls the std method; this will take precedence over Itertools.

[scottmcm]

As another example here, this would allow .Debug::fmt(f) and .Display::fmt(f), since if they’re both in scope their methods conflict (inspired by https://github.com/rust-lang/rust/pull/49068#issuecomment-375724634).

[comex]

Note that if we ever came up with some construct where foo.bar could refer to a type or module, foo.bar::baz() would have a different possible interpretation, (foo.bar)::baz().

There’s probably no reason to think we’d ever want something like that, but just for the record.

[system]

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