Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
flaper87 opened this issue Mar 31, 2014 · 30 comments

Comments

@flaper87
Copy link
Contributor

@flaper87 flaper87 commented Mar 31, 2014

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

@flaper87 flaper87 self-assigned this Mar 31, 2014
@flaper87 flaper87 changed the title opt-in built-in trait bounds RFC tracker opt-in built-in bounds traits RFC tracker Mar 31, 2014
@pnkfelix
Copy link
Member

@pnkfelix pnkfelix commented Apr 3, 2014

Marking 1.0, P-backcompat-lang.

@pnkfelix pnkfelix added this to the 1.0 milestone Apr 3, 2014
@nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Apr 15, 2014

cc me

@flaper87
Copy link
Contributor Author

@flaper87 flaper87 commented Apr 22, 2014

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.

flaper87 added a commit to flaper87/rust that referenced this issue Apr 28, 2014
flaper87 added a commit to flaper87/rust that referenced this issue Apr 28, 2014
flaper87 added a commit to flaper87/rust that referenced this issue Apr 28, 2014
This commit adds a function in vtable to find the vtables for a trait
implementation on a type.

cc rust-lang#13231
flaper87 added a commit to flaper87/rust that referenced this issue Apr 28, 2014
The bounds visitor checks looks for built-in traits implementations and
verifies that the type fulfills such trait.

cc rust-lang#13231
flaper87 added a commit to flaper87/rust that referenced this issue Apr 29, 2014
flaper87 added a commit to flaper87/rust that referenced this issue Apr 29, 2014
flaper87 added a commit to flaper87/rust that referenced this issue Apr 29, 2014
flaper87 added a commit to flaper87/rust that referenced this issue Apr 29, 2014
flaper87 added a commit to flaper87/rust that referenced this issue Apr 29, 2014
This commit adds a function in vtable to find the vtables for a trait
implementation on a type.

cc rust-lang#13231
flaper87 added a commit to flaper87/rust that referenced this issue Apr 29, 2014
The bounds visitor checks looks for built-in traits implementations and
verifies that the type fulfills such trait.

cc rust-lang#13231
flaper87 added a commit to flaper87/rust that referenced this issue Apr 30, 2014
flaper87 added a commit to flaper87/rust that referenced this issue Apr 30, 2014
flaper87 added a commit to flaper87/rust that referenced this issue Apr 30, 2014
flaper87 added a commit to flaper87/rust that referenced this issue Apr 30, 2014
flaper87 added a commit to flaper87/rust that referenced this issue Apr 30, 2014
@clarfonthey
Copy link
Contributor

@clarfonthey clarfonthey commented May 27, 2018

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
Copy link
Contributor

@dylanede dylanede commented May 27, 2018

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

@clarfonthey
Copy link
Contributor

@clarfonthey clarfonthey commented May 27, 2018

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

@mitsuhiko
Copy link
Contributor

@mitsuhiko mitsuhiko commented Jun 14, 2018

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.

dlrobertson pushed a commit to dlrobertson/rust that referenced this issue Nov 29, 2018
This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.

A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.

For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.

This breaks code like:

    #[deriving(Show)]
    struct Point2D {
        x: int,
        y: int,
    }

    fn main() {
        let mypoint = Point2D {
            x: 1,
            y: 1,
        };
        let otherpoint = mypoint;
        println!("{}{}", mypoint, otherpoint);
    }

Change this code to:

    #[deriving(Show)]
    struct Point2D {
        x: int,
        y: int,
    }

    impl Copy for Point2D {}

    fn main() {
        let mypoint = Point2D {
            x: 1,
            y: 1,
        };
        let otherpoint = mypoint;
        println!("{}{}", mypoint, otherpoint);
    }

This is the backwards-incompatible part of rust-lang#13231.

Part of RFC rust-lang#3.

[breaking-change]
@arielb1
Copy link
Contributor

@arielb1 arielb1 commented Dec 17, 2018

Added #56934

@Robbepop
Copy link
Contributor

@Robbepop Robbepop commented May 9, 2019

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
Copy link
Contributor

@WaffleLapkin WaffleLapkin commented Jul 7, 2020

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

WaffleLapkin added a commit to WaffleLapkin/minihlist that referenced this issue Jul 16, 2020
The type inequality magic was forbidden by core conclave of magicians,
see [1] and [2] for more.

This commit removes everything that depends on type inequality including:
`Exclude`, `Uniq` (that's all actually)

[1]: rust-lang/rust#29499 (comment)
[2]: rust-lang/rust#13231 (comment)
@jdahlstrom

This comment has been hidden.

@dtolnay

This comment has been hidden.

@jdahlstrom

This comment has been hidden.

@camelid camelid changed the title opt-in built-in bounds traits RFC tracker (optin_builtin_traits) Tracking Issue for auto traits (auto_traits) -- formerly called opt-in built-in traits (optin_builtin_traits) Nov 29, 2020
@camelid
Copy link
Member

@camelid camelid commented Nov 29, 2020

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

@sourcefrog
Copy link
Contributor

@sourcefrog sourcefrog commented Dec 2, 2020

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
Copy link
Member

@camelid camelid commented Dec 9, 2020

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

sadick254 added a commit to atom/atom that referenced this issue Feb 1, 2021
Traits that might be automaticially implemented for types are declared
with this keyword in the core library (see e.g.
https://github.com/rust-lang/rust/blob/master/src/libcore/marker.rs#L38).
This keyword is only valid in combination with
`![feature(optin_builtin_traits)]`
(rust-lang/rust#13231) and the normal
rust-user usually never sees this, but when editing such special files,
this might be useful.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet