Changing the type of self in methods doesn't work

[jonas-schievink]

The book states:

Methods take a special first parameter, of which there are three variants: self, &self, and &mut self.

The reference uses typed self in a few places, but doesn't explain the exact rules.

The compiler also prints redundant and misleading diagnostics:

struct S;

impl S {
    fn f(self: Vec<Self>) {}
}

gives:

<anon>:6:10: 6:28 error: mismatched self type: expected `S`: expected struct `S`, found struct `collections::vec::Vec` [E0211]
<anon>:6     fn f(self: Vec<Self>) {}
                  ^~~~~~~~~~~~~~~~~~

Since replacing Vec<Self> with Box<Self> makes the code compile, "expected struct S" isn't quite correct.

[eefriedman]

Explicitly specifying the type of self using the syntax self: Box<Self> is sort of vestigial. The feature of allowing Box<Self> as the type of self, along with the syntax for explicitly writing out the type of self, sort of slipped into 1.0 without anyone really considering the issue. The other syntax is strongly preferred.

The explicit type syntax will probably be deprecated at some point.

[steveklabnik]

/cc @rust-lang/lang , what do you think? Should we explain this more, or leave it as is?

[eddyb]

@eefriedman On the contrary, self: Foo<Self> is part of UFCS, and should be implemented at some point.
I discussed the necessary changes to the way we store inherent impls with @arielb1 some time ago, though I can't recall who was asking in the first place.

One constraint we could put on it is that Foo<Self>: Deref<Target=Self>, which is easy to check and would allow self: Rc<Self> - although, if we want to use this for traits, as well, it would have to be smarter and only allow pointers.

Foo<Self> can probably be tested for object-safe compatibility inside a trait definition by replacing Self with the trait and checking Foo<Trait>: CoerceUnsized<Foo<Self>>.
Only one leaf field can be coerced (and it's a pointer), the others are forced to have the same representation (same type, or PhantomData<T> -> PhantomData<U>).

That implies you could have, e.g. self: Triplet<String, Rc<Self>, bool> in a trait and be object-safe, with virtual calls passing that entire ADT to the virtual method, modulo the vtable pointer (though keeping it doesn't hurt anyone, either, especially if the argument is passed with indirection).

[arielb1]

@eddyb

compatibility with the trait? I would prefer to store explicit Self explicitly and use the normal check_method code.

If we want decent performance, requiring the method to appear in the autoderef loop would be nice (so do the autoderef loop in a probe, gather all methods, then sort them by priority and find the first matching one).

[eddyb]

@arielb1 Wording was unclear, I edited that bit.
I was talking about a custom self type, like self: Rc<Self> in a method inside a trait definition, that can still be treated as object-safe, given that we can prove it is pointer-like (and can thus be passed to a virtual method).
CoerceUnsize is currently only implemented on pointers and pointers with data around them, so it fits the bill.

[steveklabnik]

untagging docs and tagging with lang until @rust-lang/lang tells me what they want here

[steveklabnik]

Triage: over a year later, nothing has happened with more exotic Selfs. While it's strictly true that Box<Self> will also work, making the diagnostic technically incorrect, this seems very minor. In addition, the book isn't going to cover this until it's made more general.

So: closing this ticket, in my mind, involves fixing the diagnostic to say "or Box".

[nikomatsakis]

(FWIW, I think we really want, at minimum, *mut Self and so forth to work. Not having support for this is quite frustrating in Rayon, at least if I try to be careful about my types in unsafe code.)