Tracking Issue for auto traits (auto_traits) -- formerly called opt-in built-in traits (optin_builtin_traits)

[flaper87]

Checklist

Here is a check-list of code to write and tricky scenarios to be sure we handle:

• forbid conditional negative impls as described here
• conditional negative impls not properly enforced #23072
• impl !Pod for .. should not be legal #28475
• fix feature-gate for impl Foo for .. #23225
• defaulted traits ought to be have more restrictive coherence rules #22978
• defaulted traits should have no methods #23080 / #23117
• Add parser support for impl Foo for ..
• Port Send/Sync to use new infrastructure internally
• Add unsafe impl Send for .. / unsafe impl Sync for ..
• Object types should never match against a defaulted trait (though the object type itself may add a candidate for traits that appear in the object type)
• When a defaulted trait matches, it should impose any supertrait bounds on the matched type as nested obligations
• Be wary of type inference -- if we haven't resolved a type yet, we have to be ambiguous
• Systematic testing for constituent_types
• Coherence interaction: a defaulted trait can only be implemented for structs/enums
• Coherence interaction: a trait can only be defaulted in the crate where it is defined
• Coherence interaction: a trait can only be defaulted once
• Coherence interaction: an auto-trait can be redundantly implemented for an object that has it - #56934
• Defaulted impls cannot be generic
• Fix the interaction with PhantomData. OIBIT should treat PhantomData as if there were an instance of T reachable rather than breaking it down like it would a different struct. #23091
• Allow negative implementations for traits that have a default implementation (besides Send/Sync).

Original text

This is a tracking issue for the approved RFC opt-in-builtin-traits

Nominating

[pnkfelix]

Marking 1.0, P-backcompat-lang.

[nikomatsakis]

cc me

[flaper87]

I'm actively working on this. Unfortunately, I've moved quite slowly because of other bugs I had to fix. I hope to be able to submit a PR this week.

[clarfonthey]

Random thing I noticed is that OIBIT (hackily) allows checking for type equality (and hence type inequality):

// sealed for good measure
mod private {
    pub auto trait NotSame {}
    impl<T> !NotSame for (T, T) {}
}
use NotSame;

trait ReqDifferent<T> where (T, Self): NotSame {}
trait ReqSame<T> where (T, Self): !NotSame {}

I assume that this is not desired.

[dylanede]

No, it's not. This behaviour is a bug, See the responses to #13231 (comment)

[clarfonthey]

Wow, I completely missed that comment. Appears that this has already been discussed

[mitsuhiko]

I ran into this issue when trying to implement !Sync for a type of mine. I know you can work around this with PhantomData well but it makes for ugly error messages. I wish I could tell my users that my type is not Sync and not that *mut () or something similar contained in my type is not sync.

[arielb1]

Added #56934

[Robbepop]

With the current implementation (that might be buggy) one can solve some simple specialization cases with this feature which is nice:
https://gist.github.com/rust-play/4ea94f766d49abdbc9b2c55e49a9d2d9

[WaffleLapkin]

@clarfon note that type equality (but sadly not inequality) can be reached with simple traits on stable:

trait Id {
    type This: ?Sized;
}

impl<T: ?Sized> Id for T {
    type This = T;
}

fn assert_same<A, B>() where A: Id<This = B> {}

(playground)

[camelid]

I updated the name of this issue to be consistent with the new feature name (see #79336).

[sourcefrog]

The RFC doc talks about the Share trait, but I think that is now renamed to Sync? (Or is it / was it different?) Could I suggest the RFC text be updated, at least with a note if not a search-and-replace?

[camelid]

@sourcefrog Usually RFCs aren't updated since there are so many and it would be too much work to keep them up-to-date. But you can open a PR on rust-lang/rfcs and see if indeed it was renamed and they think it's a good idea to update the RFC.