Tracking issue for allowing overlapping implementations for marker trait

[nikomatsakis]

Tracking issue for rust-lang/rfcs#1268.

Status

• Initial implementation: #41309
• Documentation
• Move to stabilize
• Stabilization PR

Known bugs

• cross-crate support lacking?

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?

[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

[sgrif]

Looks like this doesn't work when the overlapping impls are provided by two separate crates, even if both crates have #![feature(overlapping_marker_traits)] enabled (ideally only one of the two crates would need the feature)

[nikomatsakis]

@sgrif interesting, what is the example you have in mind?

[cramertj]

One drawback mentioned in the RFC is that this feature makes it a breaking change to add default methods to a trait. Forgive me if this issue was already discussed and resolved, but I didn't see it mentioned in the RFC discussion. Prior to hearing this RFC mentioned, I never thought of "marker traits" (i.e. traits without any items) as anything special or distinct from regular traits, and I would not have expected it to be a breaking change to add default methods to them.

Personally, I'd prefer if the user had to opt-in to making a trait a "marker" trait so that they didn't unwittingly cause breakage.

[Ixrec]

One alternative I don't see in the RFC or its discussion thread is doing this only to auto traits, not to all "marker traits". Unless I missed something, all of the motivating examples (including hypotheticals) appear to be auto traits, and afaik you can't add a method to an auto trait anyway so that breaking change issue would just evaporate.

[cramertj]

Yeah, I'd be totally fine with just doing this on auto traits (whose definition is already unstable).

[Vurich]

You could explicitly seperate marker and "normal" traits by having marker traits have a different syntax, my suggestion would be:

trait MyMarker;

Similar to ZSTs. This makes it clearer when you're turning a marker trait into a non-marker trait.

[nikomatsakis]

@cramertj I would be in favor, I think, of a #[marker] attribute to signifify this behavior. There is always this line about whether attributes ought to be "semantically meaningful", but I kind of think it's ok.

[nikomatsakis]

I also don't believe this is particularly tied to auto traits.

[cramertj]

@nikomatsakis There's also precedence for semantically meaningful attributes in derives and in #[nonexhaustive] (or whatever it's called now).

[mtak-]

I needed this feature for a single trait in a personal project, and turning it on means overlapping is allowed for all of my marker traits. I'd personally like a warning issued for overlapping impls which can then be allow'ed or deny'ed. This would be similar to haskell's per instance {-# OVERLAPPING #-}.

Also, I assume this is a bug in the current implementation, but order seems to matter:

#![feature(overlapping_marker_traits)]

pub trait F {}
impl<T> F for T where T: Copy {}
impl<T> F for T where T: 'static {}

Gives the error:

error[E0310]: the parameter type `T` may not live long enough
 --> src/lib.rs:5:9
  |
5 | impl<T> F for T where T: Copy {}
  |      -  ^
  |      |
  |      help: consider adding an explicit lifetime bound `T: 'static`...
  |
note: ...so that the type `T` will meet its required lifetime bounds
 --> src/lib.rs:5:9
  |
5 | impl<T> F for T where T: Copy {}

While this (same code, different order) compiles and works as expected:

pub trait F {}
impl<T> F for T where T: 'static {}
impl<T> F for T where T: Copy {}

[mtak-]

Also the error messages when using the above trait aren't great.
https://play.rust-lang.org/?gist=707605bff9858839c0d870a5c380ab2e&version=nightly

The errors always indicate that the type needs a 'static lifetime, when it could also be Copy.

This appears to be a problem solely with lifetimes (which is my use case). If 'static is changed to Debug in the above, a less confusing error is given.

[nikomatsakis]

That particular example will be complex to make work as desired in any case, due to how region handling is done in rustc at present (e.g., #21974). In general, integrating "or" constraints and region solving is a bit tricky I suppose. I imagine we can do it by making the region checker smarter, which we have to do eventually.

[Vurich]

No matter what the actual syntax is (either an annotation or ;-vs-{}) there definitely has to be a difference between possibly-overlapping marker traits and nonoverlapping-but-empty-by-circumstance traits otherwise we'll get a host of forward-compatibility-ensuring const __UNUSED: () = (); items like we already do to prevent constructing empty-by-circumstance structs.

[scottmcm]

A thought in favour of #[marker] over trait Foo;: one could allow defaulted associated items on marker traits, and just prohibit any of the impls from overriding them.

(Inspired by a discussion with the bunny about having something like #[marker] unsafe trait Zeroable { fn zeroed() -> Self { unsafe { std::mem::zeroed() } } } in winapi.)

Edit: Also, using an attribute fits the generally-suggested "do it with a macro or attribute first, then add syntax once we have more experience" procedure.

[Vurich]

I actually quite like that idea, since it's not an uncommon pattern to have convenience functions in traits and often these will only ever be implemented in the defining crate and it might be a useful tradeoff to allow overlapping implementations at the cost of disallowing consuming crates from overriding the function body. If that was to be allowed, though, I'd prefer the name #[overlapping] instead of #[marker].

[nikomatsakis]

It seems obvious that we should make a #[marker] annotation.

[cramertj]

I was just thinking about a way to prevent users from implementing the Unpin trait for types defined by a local macro invocation, and one idea I had was to always generate an Unpin implementation that was conditional so as to prevent the user from creating their own unconditional impl. However, this would be made unsound if this feature ever stabilized. I don't know that my idea was a good one, or that it's a pattern worth encouraging, but I thought it was interesting enough to share.

[scottmcm]

@cramertj Agreed; the discussion seems to have decided that this needs to be opt-in on the trait, not something that just happens. I've started a PR towards doing so: #53693