@rustbot label -S-waiting-on-review

Thanks for this! I already see an edit to the template that could be useful, clarifying what static checks are required and linking to tests that demonstrate them, but it kind of duplicates the reference/spec work

So the report mentions that testing already happened in a few forms.

How interested would you be in other libraries using this feature? We could implement it in Masonry, but since we don't want our crate to be nightly-only, we'd have to either use a feature flag or keep it to a separate branch.

If we do end up writing an implementation, is there any kind of feedback you'd be specifically interested in?

How interested would you be in other libraries using this feature? We could implement it in Masonry, but since we don't want our crate to be nightly-only, we'd have to either use a feature flag or keep it to a separate branch.

Good question and thanks for the offer! I personally have run out of runway to work on this feature - so I'm keeping my fingers crossed that no major semantic changes are needed. Or if they are, it will need someone else to pick up the work. So, the most interesting and useful testing to me would be looking for corner cases or oddities in the current implementation which cause ICEs or other oddities. (An example is the interaction with CoercePointee which caused a crash). It's hard for me to guess how likely it is that you'd find any such problem. Obviously I hope you wouldn't, but real world testing always has a habit of finding fun surprises.

Overall: up to you! If you think it would be useful for Masonry long-term then perhaps it's worth having a play in the hopes and expectations that this will be stabilized soon and you can therefore merge it into your main branch before too long.

I'd like to ask that the cargo SemVer reference be updated to describe any new SemVer hazards that are introduced here. This doesn't have to be a stabilization blocker, but I'd appreciate it if it can be done at least shortly thereafter so I can make sure cargo-semver-checks quickly offers the best possible support for linting this excellent new functionality.

You probably want to add a #[cfg_attr(bootstrap, doc = "#[feature(arbitrary_self_types)]")] or however you spell it, so that you can conditionally gate whatever doc test under the feature gate when bootstrapping. Or just copy the item and remove the doctest from the bootstrap version.

For now I'm going to mark the doctest compile_fail just to see if we get past the miri problems and to see what else crops up.

☔ The latest upstream changes (presumably #138208) made this pull request unmergeable. Please resolve the merge conflicts.

Thrilled to see the amazing work being done here and in related PRs. My most sincere thanks and admiration for everyone helping push this work forward 🙇

I was playing with the arbitrary_self_types feature today as part of some cargo-semver-checks work, and I noticed a behavior I found surprising: Pin<P> as a receiver but does not directly allow setting P to a custom impl Receiver type. For example: playground

#![feature(arbitrary_self_types)]
pub struct Example(i64);
pub struct CustomReceiver<T>(T);
impl<T> std::ops::Receiver for CustomReceiver<T> {
 type Target = T;
}
impl Example {
 pub fn by_pinned_custom_receiver(self: std::pin::Pin<CustomReceiver<Self>>) {}
}

produces the following error:

error[E0307]: invalid `self` parameter type: `Pin<CustomReceiver<Example>>`
 --> src/lib.rs:12:44
 |
12 | pub fn by_pinned_custom_receiver(self: std::pin::Pin<CustomReceiver<Self>>) {}
 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 |
 = note: type of `self` must be `Self` or some type implementing `Receiver`
 = help: consider changing to `self`, `&self`, `&mut self`, or a type implementing `Receiver` such as `self: Box<Self>`, `self: Rc<Self>`, or `self: Arc<Self>`
For more information about this error, try `rustc --explain E0307`.

Changing self: std::pin::Pin<CustomReceiver<Self>> to self: std::pin::Pin<&mut CustomReceiver<Self>> (i.e. changing Pin<P> from P = CustomReceiver<Self> to P = &mut CustomReceiver<Self>) avoids the error.

Perhaps this is entirely expected, and it is merely my naïveté causing me to be surprised. I thought I'd flag it on the off chance it either is genuinely unexpected, or deserving of closer documentation than the present trait Receiver and Pin-as-receiver-type documentation currently offer.

Yeah, we can't impl<T: Receiver> Receiver for Pin<T> because of the blanket Deref impl (I think it's the same underlying issue as discussed further up, see in particular this response).

Neat, so it sounds like this is a known issue — thank you. This implication of the blanket Deref impl wasn't obvious to me. Is this worth specifically calling out in docs? I'll leave that question in the capable hands of everyone here 🙏

Thanks again for driving this amazing work forward!

That is a particularly unfortunate and motivating example of it though. Thanks for mentioning that @obi1kenobi.

Here's that spelled out a bit:

Playground link

That is motivating enough we should discuss it -- I don't recall us ever considering this one, and it is bad -- to see how we might eventually be able to address it.

@rustbot labels +I-lang-nominated

@rfcbot concern discuss-plan-for-pin

I started a conversation on maybe allowing overlapping impls only for a impl<T: ?Sized + Receiver> Receiver for Pin<T> in core:
#t-types > impl Receiver for Pin and overlapping impls

alternative idea: #t-lang > impl Receiver for Pin and impl Receiver for impl Deref

We discussed this Pin interaction in the lang team meeting. I have to admit I'm a bit worried about the relationship between Deref and Receiver, we may be missing something here.

I feel like the actual design we want is to have these two traits:

trait Deref: Receiver {
 fn deref(&self) -> &Self::Target;
}
trait Receiver {
 type Target;
}

and then to have an impl Deref for Foo { type Target = X; } be equivalent two implementing both Deref and Receiver. This idea of having an impl be able to implement supertraits if it specifies their items is one that I think a lot of us want, but is obviously a distinct feature worthy of discussion on its own. For the moment, let's imagine that we just, for backwards compatibility reason, hardcode the behavior that writing an impl Deref that includes Target expands to both an impl Deref and an implementation of Receiver.

If we did this, I think it actually works very well for most smart pointer types:

struct MyPointer<T> { }
impl<T: ?Sized> Deref for MyPointer<T> {
 type Target = T;
 fn deref(&self) -> Self::Target { ... }
}
// Converted to
impl<T: ?Sized> Deref for MyPointer<T> {
 fn deref(&self) -> Self::Target { ... }
}
impl<T: ?Sized> Receiver for MyPointer<T> {
 type Target = T;
}

If however you have your own Pin-like type, you get a problem:

struct MyPin<T> { }
impl<P: Deref> Deref for MyPin<P> {
 type Target = P::Target;
 fn deref(&self) -> 
}
// Converted to
impl<T: Deref> Deref for MyPointer<T> {
 fn deref(&self) -> Self::Target { ... }
}
impl<T: Deref> Receiver for MyPointer<T> {
 type Target = T;
}

...but you probably wanted that final impl to be

impl<T: Receiver> Receiver for MyPointer<T> {
 type Target = T;
}

However, this is not obviously a problem. I believe you can just break the impl into two impls.

Proposal in short

• Change to Deref: Receiver and move Target to Receiver
• In compiler front-end, split apart impls of Deref that define Target to impl both Deref and Receiver

Questions then:

• For types team, does the above seem reasonable? Am I missing something?
• I am also assuming that <T as Deref>::Target continues to work if Deref: Receiver and Target is located in Receiver, but I can't 100% remember if that's true
• For lang team would seem to be: are we willing to special case impls of Deref on the premise that we will generalize this later? It's a bit of a "confidence call". And, if so, can/should we prioritize this work?
• And in general, given that this is a non-trivial change, how do we feel about pushing back the stabilization schedule on this.

• I am also assuming that <T as Deref>::Target continues to work if Deref: Receiver and Target is located in Receiver, but I can't 100% remember if that's true

that does not work, so we'd need a special exception to make it work.

@programmerjake I think we could (and should) make it work then, yes.

While working on opaque types in the new solver, I encountered https://github.com/rust-lang/rust/blob/master/tests/ui/methods/call_method_unknown_referent2.rs

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=62051dbf3ec128a95b663f91d0ed538f

#![feature(arbitrary_self_types)]
struct SmartPtr<T>(T);
impl<T> core::ops::Receiver for SmartPtr<T> {
 type Target = T;
}
impl<T> SmartPtr<T> {
 fn foo(&self) -> usize { 3 }
}
fn main() {
 let ptr = SmartPtr(Default::default());
 // Ensure calls to outer methods work even if inner methods can't be
 // resolved due to the type variable
 assert_eq!(ptr.foo(), 3);
 let _: SmartPtr<u32> = ptr;
}

This behavior was surprising to me as it differs from autoderef steps via Deref

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=5d19da1234038757b22534afe5f4847c

#![feature(arbitrary_self_types)]
use std::ops::Deref;
struct SmartPtr<T>(T);
impl<T> Deref for SmartPtr<T> {
 type Target = T;
 fn deref(&self) -> &Self::Target {
 &self.0
 }
}
impl<T> SmartPtr<T> {
 fn foo(&self) -> usize { 3 }
}
fn main() {
 let ptr = SmartPtr(Default::default());
 assert_eq!(ptr.foo(), 3); //~ ERROR type annotations needed for `SmartPtr<_>`
 let _: SmartPtr<u32> = ptr;
}

It also diverges from the existing lint/hard error for raw-pointers

edition 2015: emits a lint
edition 2018: results in a hard error

#![feature(arbitrary_self_types)]
#![feature(rustc_attrs)]
impl<T> *const T {
 #[rustc_allow_incoherent_impl]
 fn foo(&self) -> usize { 3 }
}
fn main() {
 let ptr = std::ptr::null();
 assert_eq!(ptr.foo(), 3);
 let _: *const u32 = ptr;
}

This is caused by the following uncommented line which always uses the final type from the Deref chain instead of the potentially longer Receiver chain.

Is this intended behavior?

There's a Zulip thread discussing if Deref and Receiver should be related at all via trait bounds or blanket impls. I now think they should be unrelated.