Tracking issue for allowing overlapping implementations for marker trait

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

History

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

Prior to stabilization

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.

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:

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).
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.

Add the ability to work with boxed expressions

Add basic support for additional expressions in from clause

@nrc

@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.

@sgrif

@sgrif swapped labels

Add a function for SQL `EXISTS` expressions.

@rustbot

I'm nominating this to @rust-lang/lang and @rust-lang/types ---

I'd like to get a temperature check on this feature. Quick summary is that it lets you put #[marker] on a trait and then permit overlap.

From lang, I'm curious as to whether folks still think this is desirable. (I do, though I'm potentially open to bike-shedding on the details -- but this precise scenario comes up all the time.)

From types, I'm curious as to whether folks are aware of impl problems, how this fits with the new solver, etc. Seems like a great candidate to target with a-mir-formality and spec work for testing out a new process.

@rustbot labels +I-lang-nominated +I-types-nominated

I think it goes particularly well with rust-lang/rfcs#3678, since then #[marker] traits could have methods so long as they're final fn.

That would allow, for example,

#[marker]
trait Copy : Clone {
    #[final]
    fn copy(&self) -> Self { *self }
}

@rustbot

@rustbot labels -I-lang-nominated

We talked about this during our lang day in December, and we touched on it briefly again today. We're feeling favorably toward allowing overlap on marker traits that are explicitly designated, and are looking forward to seeing concrete next steps on this nominated for us.

This was discussed a bit in the T-types/nominated zulip stream. A proper implementation of this feature needs OR region constraints and is blocked on -Znext-solver everywhere

Rollup merge of rust-lang#160705 - WaffleLapkin:unreserve_Fromᐸǃᐳ, r=…

Unrolled build for #160705 in rollup 161672

Rollup merge of #160705 - WaffleLapkin:unreserve_Fromᐸǃᐳ, r=JonathanB…

Navigation Menu

Repository navigation

Tracking issue for allowing overlapping implementations for marker trait #29864

Status

Known bugs

History

Prior to stabilization

Other notes

78 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for allowing overlapping implementations for marker trait #29864

Description

Status

Known bugs

History

Prior to stabilization

Other notes

Activity

nikomatsakis commented on Nov 18, 2015

sgrif commented on Nov 15, 2016

nikomatsakis commented on Nov 15, 2016

78 remaining items

nikomatsakis commented on Dec 26, 2024

scottmcm commented on Jan 8, 2025

traviscross commented on Jan 8, 2025

BoxyUwU commented on Jan 8, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions