Tracking issue for RFC 3519: arbitrary_self_types · Issue #44874 · rust-lang/rust (original) (raw)

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 however not 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_pointers feature gate
• Rename the old Receiver trait -- currently being run through crater
• Land the new Receiver trait without it doing anything.
• Switch over the method resolution to use the Receiver trait, if the arbitrary_self_types feature is enabled. The main event.
• Add diagnostics for the !Sized case and the NonNull etc. cases.
• Update the Rust reference.
  • Arbitrary self types v2: update reference. reference#1699
  • Method call reference: major rewrite reference#1725
• Add documentation to the dev guide. See the instructions.
• Add formatting for new syntax to the style guide. See the nightly style procedure.
• Clear out stabilization blockers.
  • Make ptr_cast_add_auto_to_object lint into hard error #136764
  • [WIP] Forbid object lifetime changing pointer casts #136776
• Stabilize!
  • Arbitrary self types v2: stabilize #135881

Unresolved Questions

None.

Notable for Stabilization

• Arbitrary self types v2: no deshadow pre feature. #134524

Related

• Changing the type of self in methods doesn't work #27941

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

• 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

See #27941 (comment)

Handling of inference variables

Calling a method on *const _ could now pick impls of the form

impl RandomType { fn foo(*const Self) {} }

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 allowing dyn Foo to be object safe unless bar was an unsafe fn

trait Foo { fn bar(self: *const Self); }

fn main() { // creates a raw pointer with a garbage vtable let foo: *const dyn Foo = unsafe { mem::transmute([0usize, 0x1000usize]) }; // and call it foo.bar(); // this is UB }

However, even today you could UB in safe code with mem::size_of_val(foo) on the above code, so this might not be actually a problem.

More information

There's no reason the self syntax has to be restricted to &T, &mut T and Box<T>, we should allow for more types there, e.g.

trait MyStuff { fn do_async_task(self: Rc); }

impl MyStuff for () { fn do_async_task(self: Rc) { // ... } }

Rc::new(()).do_async_stuff();