Tracking Issue for auto traits (auto_traits) -- formerly called opt-in built-in traits (optin_builtin_traits) #13231
Comments
Marking 1.0, P-backcompat-lang. |
cc me |
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. |
This commit adds a function in vtable to find the vtables for a trait implementation on a type. cc rust-lang#13231
The bounds visitor checks looks for built-in traits implementations and verifies that the type fulfills such trait. cc rust-lang#13231
This commit adds a function in vtable to find the vtables for a trait implementation on a type. cc rust-lang#13231
The bounds visitor checks looks for built-in traits implementations and verifies that the type fulfills such trait. cc rust-lang#13231
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. |
No, it's not. This behaviour is a bug, See the responses to #13231 (comment) |
Wow, I completely missed that comment. Appears that this has already been discussed |
I ran into this issue when trying to implement |
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]
Added #56934 |
With the current implementation (that might be buggy) one can solve some simple specialization cases with this feature which is nice: |
@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> {} |
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)
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
I updated the name of this issue to be consistent with the new feature name (see #79336). |
The RFC doc talks about the |
@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. |
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.
Checklist
Here is a check-list of code to write and tricky scenarios to be sure we handle:
impl !Pod for ..
should not be legal #28475impl Foo for ..
#23225impl Foo for ..
Send/Sync
to use new infrastructure internallyunsafe impl Send for ..
/unsafe impl Sync for ..
constituent_types
Original text
This is a tracking issue for the approved RFC opt-in-builtin-traits
Nominating
The text was updated successfully, but these errors were encountered: