Tracking issue for allowing overlapping implementations for marker trait

[nikomatsakis]

Tracking issue for rust-lang/rfcs#1268.

Status

• Initial implementation: Implement RFC 1268 "Allow overlapping implementations for marker traits" #41309
• Documentation
• Move to stabilize
• Stabilization PR

Known bugs

• cross-crate support lacking?
• broken interaction between marker traits, lifetimes, and caching #102360

History

• initial implementation Implement RFC 1268 "Allow overlapping implementations for marker traits" #41309
• Support an explicit annotation for marker traits #53693

Prior to stabilization

1. Is it ok that adding items to a previously empty trait is a breaking change? Should we make declaring something a marker trait more explicit somehow? --> resolved by adding explicit #[marker] annotation, see Support an explicit annotation for marker traits #53693

Other notes

In #96766 we decided NOT to disable the orphan check for marker traits as part of this work (just the overlap check), which was a proposed extension.

[nikomatsakis]

With respect to the second question of whether we should make a more explicit notion of marker trait, I have been pondering this since the RFC discussion. On the one hand, there are a number of places in Rust today where going from nothing to something is a breaking change: adding a private field to a struct, for example.

The difference here I think is that:

1. Given the ability to specify defaults, adding an item to a trait does not necessarily have to be a breaking change otherwise (though methods and fns can cause new ambiguities etc).
2. If there are impls that are taking advantage of the ability to overlap, there may just be no way to port older code forward, because it would require overlap.

However, the second point depends a lot on the fate of specialization. If we wind up adopting specialization, and in particular a model that does not require strict subsets, then it would still be possible to adapt existing impls. This makes me a lot less worried. Of course, implementing that form of specialization is tricky, but not (I don't think...) that much trickier than implementing THIS suggestion. The hard part in both cases is the potential for overlap.

[sgrif]

@nrc This has the RFC implemented label, but I don't think it has been. If it has, is there a feature gate that I'm missing? If it hasn't been implemented, is there anything I can do to help push this along? It's now been a year since the RFC was accepted.

[nikomatsakis]

@sgrif swapped labels