Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork14.5k
Description
This is the tracking issue for RFC 3519: Arbitrary self types v2.
The feature gate for this issue is#![feature(arbitrary_self_types)].
About tracking issues
Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is howevernot meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Current plan is:
- Fix the current lifetime elision bugs
- Search for potentially conflicting method candidates
- Block generic arbitrary self types.
- Introduce an
arbitrary_self_types_pointersfeature gate - Rename the old
Receivertrait -- currently being run through crater - Land the new
Receivertrait without it doing anything. - Switch over the method resolution to use the
Receivertrait, if thearbitrary_self_typesfeature is enabled. The main event. - Adddiagnostics for the
!Sizedcase and theNonNulletc. cases. - Update the Rust reference.
- Add documentation to thedev guide. See theinstructions.
- Add formatting for new syntax to thestyle guide. See thenightly style procedure.
- Decide whether
DerefandReceivertraits should be decoupled (cc@dingxiangfei2009). - (In the alternate:) Make
Derefa subtrait ofReceiver. - Clear out stabilization blockers.
- Stabilize!
Unresolved Questions
None.
Notable for Stabilization
Related
Implementation history
- Fix ambiguous cases of multiple & in elided self lifetimes #117967
- Arbitrary self types v2: pointers feature gate. #129664
- Reject generic self types. #130098
- Rename Receiver -> LegacyReceiver #130225
- Arbitrary self types v2: (unused) Receiver trait #132144
- Arbitrary self types v2: main compiler changes #132961
- Arbitrary self types v2: adjust diagnostic. #134262
- Arbitrary self types v2: Weak & NonNull diagnostics #134264
- Arbitrary self types v2: better feature gate test #134271
- Arbitrary self types v2: niche deshadowing test #134509
- Arbitrary self types v2: roll loop. #134521
- Arbitrary self types v2: no deshadow pre feature. #134524
- Arbitrary self types v2: unstable doc updates. #134525
- Arbitrary self types v2: explain test. #136124
(Below follows content that predated the accepted Arbitrary Self Types v2 RFC.)
Details
- figure out the object safety situation
- figure out the handling of inference variables behind raw pointers
- decide whether we want safe virtual raw pointer methods
Object Safety
Handling of inference variables
Calling a method on*const _ could now pick impls of the form
implRandomType{fnfoo(*constSelf){}}
Because method dispatch wants to be "limited", this won't really work, and as with the existing situation on&_ we should be emitting an "the type of this value must be known in this context" error.
This feels like fairly standard inference breakage, but we need to check the impact of this before proceeding.
Safe virtual raw pointer methods
e.g. this is UB, so we might want to force the call<dyn Foo as Foo>::bar to be unsafe somehow - e.g. by not allowingdyn Foo to be object safe unlessbar was anunsafe fn
traitFoo{fnbar(self:*constSelf);}fnmain(){// creates a raw pointer with a garbage vtablelet foo:*constdynFoo =unsafe{ mem::transmute([0usize,0x1000usize])};// and call it foo.bar();// this is UB}
However, even today you could UB in safe code withmem::size_of_val(foo) on the above code, so this might not be actually a problem.
More information
There's no reason theself syntax has to be restricted to&T,&mut T andBox<T>, we should allow for more types there, e.g.
traitMyStuff{fndo_async_task(self:Rc<Self>);}implMyStufffor(){fndo_async_task(self:Rc<Self>){// ...}}Rc::new(()).do_async_stuff();