Document how self: Self receiver types *actually* interact with object safety

[steffahn]

Fixes #1247

The description here on how this works is based purely on experiments on what the compiler does or does not accept (without unstable features), not on any inspection of the implementation in rustc. The term of “implicitly non-dispatchable functions” is one I just made up, as far as I’m aware, because it makes sense in this context. The motivation of future-compatibility is just my guess, too.

I might want to read up some actual sources around relevant RFCs and/or PRs, for precise (intended) behavior, terminology, and motivation of the behavior of self: Self but not Self: Sized methods in traits.

For review, especially if any of my “guesses” here are wrong, I’d thus also appreciate relevant links to relevant discussions to learn from.

[steffahn]

cc @QuineDot since you recently opened #1445, so you might have some ideas or feedback here

[QuineDot]

See this PR -- it's not just Self: Sized that makes a method non-dispatchable, it's TypeInvolvingSelf: NonAutoTrait... plus some others. See also.

I haven't experimented enough to feel 💯 confident in what is and isn't accepted, and there is some wonkiness around the check. Such as the "empty bounds" in the examples below...

Example where clauses which are fine (do not make the method non-dispatchable):

• Self: Send
• Self: 'a
• Self:
• Self::AssociatedType: Debug
• Box<Self>: 'a

Example where clauses which make the method non-dispatchable:

• Self: Debug
• Box<Self>: Debug
• Box<Self>: Send
• Box<Self>: 🤷
• dyn Trait<Assoc = Box<Self>>: Debug

Tangential aside: Self: Sized in an implied bound (e.g. where Self: Clone) also counts as explicitly non-dispatchable.

[traviscross]

We reviewed this PR in the rustdocs call, and we've asked for review of this by the types team in:

• Review of Reference change regarding receivers and object safety rust#127251

[compiler-errors]

One idea, this otherwise looks fine to me

[compiler-errors]

I wonder if we could split this out to a "A type is a dispatchable receiver if it's one of: "

then we can say Pin<P> if P is a dispatchable receiver

[lcnr]

that terminology feels weird, fn foo<T> is also "implicitly non-dispatchable", isn't it?

All associated functions must either be dispatchable from a trait object or must not be applicable to trait objects

Suggested change

	or be explicitly or implicitly non-dispatchable.
	or must not be applicable to trait objects.

[lcnr]

Suggested change

	* Explicitly non-dispatchable functions must:
	* Have a `where Self: Sized` bound.
	* Implicitly non-dispatchable functions must:
	* Have the receiver type `Self` (i.e. `self`)
	* Fulfill all the conditions of dispatchable functions, except for the receiver type.
	* Non-applicable functions have either:
	* a `where Self: Sized` bound.
	* the receiver type `Self` (i.e. `self`) and fulfill all the conditions of dispatchable functions, except for the receiver type.

[lcnr]

Suggested change

	Methods with `Self` receiver type are implicitly non-dispatchable
	(“non-dispatchable” means that they cannot be called on trait object types), but
	[might become dispatchable in future versions of Rust](https://github.com/rust-lang/rust/issues/48055).
	Methods with `Self` receiver type are currently non-dispatchable
	("non-dispatchable" means that they cannot be called on trait object types), but
	[might become dispatchable in future versions of Rust](https://github.com/rust-lang/rust/issues/48055).

[rustbot]

☔ The latest upstream changes (possibly bf115a4) made this pull request unmergeable. Please resolve the merge conflicts.