Arbitrary self types v2: no deshadow pre feature. by adetaylor · Pull Request #134524 · rust-lang/rust (original) (raw)

Good question.

Existing code which could break must fit these criteria:

• It uses an existing standard library smart pointer type - Box, Pin, Rc or Arc.
• The smart pointer type must have an inherent method (not just an associated function)
• Case A:
  • That standard library method must take self by value
  • The referent must have an identically named method which takes self: &SmartPointerType<Self> or self: &mut SmartPointerType<Self>
• Case B:
  • That standard library method must take &self
  • The referent must have an identically named method which takes self: &mut SmartPointerType<Self>

Standard library methods which might cause these problems:

• Case B: Pin::as_ref
• Case A: Pin::map_unchecked
• Case A: Pin::get_ref
• Case A: Pin::into_ref
• Case A: Pin::get_unchecked_mut
• Case A: Pin::map_unchecked_mut
• There are no cases in Rc, Box or Arc

So folks will get broken if, and only if, they have types with any of these methods:

fn as_ref(self: &Pin) fn as_ref(self: &mut Pin) fn map_unchecked(self: &mut Pin) fn get_ref(self: &mut Pin) fn into_ref(self: &mut Pin) fn get_unchecked_mut(self: &mut Pin) fn map_unchecked_mut(self: &mut Pin)

But here's the thing. As of now, I don't believe there would be any way to call those methods. Because method resolution would always pick the method on Pin rather than the inner method. You could call these methods through UFCS, but in practice I don't think anyone will have added these methods to any types, because aside from calling them using UFCS, it's completely pointless to add these methods.

Therefore - I think in practice we won't break anyone.

But, I did want us to consider this fully and decide if it's OK to take this theoretical risk during stabilization instead of now, hence raising this PR.