Arbitrary self types v2 by adetaylor · Pull Request #3519 · rust-lang/rfcs (original) (raw)

Ok so I did a thorough experiment (try out my madness here). It appears the algorithm picks 4 over 3 in my list above, which could appear to break my proposal. The rest of the order is ok, so today's method resolution algorithm is compatible with this ordering:

a. foo(&Arc<Box<Self>>) on T
b. foo(&Arc<Self>) on Box<T>
c. foo(&self) on Arc<T>
d. foo(&Box<Self>) on T
e. foo(&self) on Box<T>
f. foo(&self) on T

However! All is still fine. Indeed, if Arc was not Deref, we would only consider the following cases:

a. foo(&Arc<Box<Self>>) on T
b. foo(&Arc<Self>) on Box<T>
c. foo(&self) on Arc<T>

Here adding an inherent method to Arc would not be a breaking change. The reason adding an inherent method to Arc is breaking is because Arc: Deref, and we already know that adding methods to Deref types is a breaking change.

In short: if we take the current implementation of arbitrary_self_types and simply accept more cases that are currently errors, we can get the order above and the property that "adding inherent methods to a Receiver type is not a breaking change".

Moreover! Given that the only stable Receiver types don't have inherent methods (I think, right?), I believe we can even change this order a bit without breakage. It will only break users of the unstable arbitrary_self_types feature in that one corner case. So we can pick my initial "most specific first" order too if we prefer.

I think that proves that we're good? Did I miss anything?