Tracking Issue for RFC: Supertrait Item Shadowing

[pnkfelix]

This is a tracking issue for:

• RFC: Supertrait item shadowing rfcs#2845
• Supertrait item shadowing v2 rfcs#3624

The feature gate for the issue is #![feature(supertrait_item_shadowing)].

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Accept an RFC.
  • RFC: Supertrait item shadowing rfcs#2845
  • Supertrait item shadowing v2 rfcs#3624
• Implement in nightly.
  • Implement RFC 3624 supertrait_item_shadowing (v2) #125782
• Add documentation to the dev guide.
  • See the instructions.
• Add documentation to the reference.
  • See the instructions.
• Add formatting for new syntax to the style guide.
  • See the nightly style procedure.
• Stabilize.
  • See the instructions.

Unresolved Questions

TODO.

Related

• RFC: Supertrait item shadowing rfcs#2845
• Supertrait item shadowing v2 rfcs#3624
• Implement RFC 3624 supertrait_item_shadowing (v2) #125782

[dtolnay]

@rust-lang/libs-api — this change is relevant to our ability to add things like Iterator::intersperse which used to introduce ambiguities against Itertools::intersperse. After this language change it would no longer be ambiguous because trait Itertools: Iterator {...}. Thus downstream uses of .intersperse(...) would resolve to the Itertools one since that's the subtrait.

• Stabilizing Iterator::intersperse breaks a large number of crates #88967

[the8472]

For the Iterator/Itertools case it would be necessary to shadow based on the explicit import of Itertools vs. the implicit import via the prelude.

Currently the RFC only concerns itself with traits being brought into scope via generics or trait objects, not via the prelude.

To resolve this issue, this RFC proposes the following: If the user does not explicitly bring the supertrait into scope themselves, the subtrait should "shadow" the supertrait, resolving the current ambiguity in favor of the subtrait.
[...]
When using a trait as a bound in generics, or using a trait object, a trait with a supertrait will only bring the supertrait's items into scope if it does not define an item with the same name itself.

So the scope of this issue would have to be widened a bit.

[lcdr]

This is correct, the RFC explicitly only concerns itself with generics and trait objects.
Note however that glob imports have long been known to have the potential to induce breakage: the Semver and API Evolution RFC points out that glob imports can effectively make any addition of public items a breaking change. It then argues that since a glob import could always have been written as a list of explicit imports, it is considered an acceptable minor change to add new items. Interestingly enough, the RFC suggests glob shadowing as a solution to this issue. However as far as I'm aware there hasn't been a glob shadowing RFC actually submitted.

Similar concerns to what the RFC covers however also apply to the case where both supertrait and subtrait are used, without glob imports being involved at all. Unfortunately in this particular case it's a much more difficult decision whether to shadow or not to shadow - this RFC argued that in the case of generics and trait objects, Rust's implicit bringing into scope of supertrait items was counterintuitive to a user who just imported the subtrait, without even possibly knowing of the supertrait. However, in this case, the user would have consciously imported both traits. It could be argued that the better choice would be to refuse to automatically shadow and force the user to disambiguate, or, on the other hand, that it's better to keep behavior consistent with the subtrait-shadows-supertrait rule in the RFC. It'd be interesting to hear T-lang's opinions on this issue.

[the8472]

Well, the std prelude (which is what causes #88967) isn't an explicit glob import either, it's fully implicit.

[lcdr]

Ah, I thought you were talking about a prelude in Itertools.

[petrochenkov]

I remember looking at the method resolution logic (excluding auto(de)ref) in the compiler a couple of years ago, and not liking what I've seen.

Treating methods from generic parameter bounds as inherent (bad idea, IMO), treating Trait methods on dyn Trait as inherent (bad idea, IMO), not considering Trait methods on impl Trait at all (bad idea, IMO, #41221), filtering of private methods (needs to have some priority relative to supertrait item shadowing), filtering of unstable methods (needs to have some priority relative to supertrait item shadowing).

I wish that area got some principled common vision (and corresponding bugfixing) before new features are added.