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