Tracking issue for RFC 3519: `arbitrary_self_types`

[arielb1]

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.
• Add documentation to the dev guide. See the instructions.
• Add formatting for new syntax to the style guide. See the nightly style procedure.
• Stabilize!

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

TODO.

---

(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<Self>);
}

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

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

[porky11]

Why would you need this?
Why wouldn't you write an impl like this:

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

I'd rather define the trait different. Maybe like this:

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

In this case, Rc would be a trait type. If every generic type implemented a specific trait (this could be implemented automatically for generic types) this seems more understandable to me.

[cuviper]

This could only be allowed for trait methods, right?

For inherent methods, I can't impl Rc<MyType>, but if impl MyType can add methods with self: Rc<Self>, it seems like that would enable weird method shadowing.

[arielb1]

@cuviper

This is still pending lang team decisions (I hope there will be at least 1 RFC) but I think it will only be allowed for trait method impls.

[arielb1]

@porky11

You can't implement anything for Rc<YourType> from a crate that does not own the trait.

[arielb1]

So changes needed:

• remove the current error message for trait methods only, but still have a feature gate.
• make sure fn(self: Rc<Self>) doesn't accidentally become object-safe
• make sure method dispatch woks for Rc<Self> methods
• add tests

[SimonSapin]

I’ll look into this.

[arielb1]

Note that this is only supported to work with trait methods (and trait impl methods), aka

trait Foo {
    fn foo(self: Rc<Self>);
}
impl Foo for () {
    fn foo(self: Rc<Self>) {}
}

and is NOT supposed to work for inherent impl methods:

struct Foo;
impl Foo {
    fn foo(self: Rc<Self>) {}
}

[SimonSapin]

I got caught in some more Stylo work that's gonna take a while, so if someone else wants to work on this in the meantime feel free.

[kennytm]

Is this supposed to allow any type as long as it involves Self? Or must it impl Deref<Target=Self>?

trait MyStuff {
    fn a(self: Option<Self>);
    fn b(self: Result<Self, Self>);
    fn c(self: (Self, Self, Self));
    fn d(self: Box<Box<Self>>);
}

impl MyStuff for i32 {
   ...
}

Some(1).a();  // ok?
Ok(2).b();  // ok?
(3, 4, 5).c(); // ok?
(box box 6).d(); // ok?