opt-in built-in bounds traits RFC tracker (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.

[nikomatsakis]

@dylanede hmm, sorry I failed to answer your question before. I'm sorry to say this, but your code snippet is not expected to work.

In particular, the way to think about it is that, by adding a negative impl for (T, T), you have suppressed the default impl that would have been provided -- so now there is no positive impl! Therefore, (X, Y): NotSame cannot hold for any tuple. (But, (X, Y): !NotSame, if we ever added negative impls, would only hold if X == Y; otherwise, (X, Y) neither implements NotSame nor !NotSame, a situation which @withoutboats artfully described as (X, Y): ?NotSame.)

Note that the behavior for your example is inconsistent already. For example, while your code compiles, this similar snippet does not.

I had to dig a bit into the code to see why your example worked at all: the answer is that the "first pass" test which tries to unify with various impls fails to unify for types like u32 and i32 -- it will basically succeed "modulo regions". So then later when we check to see if there were any negative impls that applied, we find out that there were not (in the case of u32, i32) but that there are (in the case of &'static u32, &'a u32). If we were properly implementing the RFC the way that I had intended to amend it, we would always find applicable negative impls (in fact, until such time as we add general negative reasoning, I had intended to make the negative impl you wrote illegal -- you would have to write negative impls that are "fully general", much like the rules we enforce for Drop.)

[chriskrycho]

This is… beyond me. Someday maybe. 😬

But I'm trying to document all the things, so: can someone take a gander at the reference and the book and give me a reasonable summary of the extent to which this is or isn't documented?

[Zoxc]

I just wanted to note that if we add immovable types in it's current form, default traits would have to be declared with trait Send: ?Move {} to avoid having Move as a supertrait (which has soundness bugs).

[bstrie]

Resuming the bikeshed which I had previously missed, not quite sold on the new auto trait syntax as of #45247 (though nevertheless an improvement over the old). Not only is it a new keyword (a heavyweight addition) for a feature that is intended to be incredibly obscure, but it risks confusion for people coming from C++.

In #45247 an alternative of #[autoderive] was floated and seemed to have quite some support. I think it makes sense as a general policy for us to prefer attributes/macros for obscure features, and later offer keywords/operators if anyone demands (which was the trajectory for ?, and the possible trajectory for async/await, and unlikely to ever occur for autotraits IMO).

[clarcharr]

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)

[clarcharr]

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