Proposal: Remove arbitrary_self_types_pointers feature

[ShaddyDC]

This PR proposes the complete removal of the unstable feature arbitrary_self_types_pointers.

1. Introduction

The arbitrary_self_types_pointers feature (tracked under the same issue as arbitrary_self_types - #44874) was introduced to extend the arbitrary self types mechanism to raw pointers, allowing methods to be declared with and resolved through self: *const Self or self: *mut Self receivers.

We propose removing this feature entirely.

2. What the feature allows right now

Currently, with #![feature(arbitrary_self_types_pointers)] enabled, the compiler allows:

• Methods to be declared with raw pointer receivers:

  impl Foo {
      fn bar(self: *const Self) {}
  }

• The method resolution algorithm to traverse raw pointer types in the autoderef chain during receiver search.

3. Removal motivation

There are several design and safety issues with allowing raw pointer receivers:

• Bypassing Receiver guidelines: Raw pointers do not implement the Receiver trait, and their support was hardcoded directly into the compiler's well-formedness checks (wfcheck.rs) and method resolution search (probe.rs). This breaks the principle that arbitrary self types should be driven by the Receiver trait.
• Unsafe ergonomics in safe contexts: By incorporating raw pointers directly into the method resolution autoderef loop, method calls can implicitly dereference raw pointers without requiring unsafe. See for example the test tests/ui/cast/ptr-to-trait-obj-different-regions-lt-ext.rs that, after the feature removal, now requires unsafe to be used.
• Complexity: It creates complicated instances of method shadowing as demonstrated in tests/ui/self/arbitrary_self_types_niche_deshadowing.rs.

4. Risk / Impact

• Very Low: This is an unstable feature that was never close to stabilization. The feature's documentation explicitly advises against using it.
• There should be no impact on stable Rust code. Any unstable crates relying on raw pointer receivers can migrate to wrapper types that implement Receiver (which is the recommended practice).

#44874
r? @dingxiangfei2009

[rustbot]

miri is developed in its own repository. If possible, consider making this change to rust-lang/miri instead.

cc @rust-lang/miri

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @dingxiangfei2009 (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[RalfJung]

Has this been MCP'd / discussed on a team level before? The tracking issue does not seem to contain any such discussion. What motivated you to propose this change, out of the blue, as your first PR for Rust?

Raw pointer receivers could help in improving the ergonomics of working with raw pointers -- and that is an area that desperately needs improvement. So removing them does not seem like a step in the right direction.

What happens with stable methods that have raw ptr receivers, such as this?

[RalfJung]

See for example the test tests/ui/cast/ptr-to-trait-obj-different-regions-lt-ext.rs that, after the feature removal, now requires unsafe to be used.

Where does this test do auto-deref?

Your patch for that file turns a raw pointer into a reference. Obviously that requires unsafe. This does not confirm your claim.

method calls can implicitly dereference raw pointers without requiring unsafe

That would be a soundness bug. Do you have an example for this? What is your source for this claim?

Note that generally we expect PR summaries to be written by the PR author. LLMs tend to generate incorrect and/or useless summaries. Your summary seems to contain factual mistakes, making it likely that you copied it without fact-checking it yourself. Please do not do that, it is disrespectful of maintainer's time.

[rust-log-analyzer]

The job x86_64-gnu-pre-stabilization failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

8 
- error[E0055]: reached the recursion limit while auto-dereferencing `MySmartPtr<Content>`
-   --> $DIR/arbitrary_self_type_infinite_recursion.rs:12:19
-    |
- LL |   fn method(self: MySmartPtr<Self>) { // note self type
-    |                   ^^^^^^^^^^^^^^^^ deref recursion limit reached
-    |
-    = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`arbitrary_self_type_infinite_recursion`)
-    = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no`
- 
18 error[E0307]: invalid `self` parameter type: `MySmartPtr<Content>`
---
To only update this specific test, also pass `--test-args self/arbitrary_self_type_infinite_recursion.rs`

error: 1 errors occurred comparing output.
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/checkout/tests/ui/self/arbitrary_self_type_infinite_recursion.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1" "--target=x86_64-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/self/arbitrary_self_type_infinite_recursion" "-A" "unused" "-W" "unused_attributes" "-A" "internal_features" "-A" "incomplete_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers"
stdout: none
--- stderr -------------------------------
error[E0055]: reached the recursion limit while auto-dereferencing `MySmartPtr<Content>`
##[error]  --> /checkout/tests/ui/self/arbitrary_self_type_infinite_recursion.rs:12:19
   |
LL |   fn method(self: MySmartPtr<Self>) { // note self type
   |                   ^^^^^^^^^^^^^^^^ deref recursion limit reached
   |
   = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`arbitrary_self_type_infinite_recursion`)

error[E0307]: invalid `self` parameter type: `MySmartPtr<Content>`
##[error]  --> /checkout/tests/ui/self/arbitrary_self_type_infinite_recursion.rs:12:19
   |
LL |   fn method(self: MySmartPtr<Self>) { // note self type
   |                   ^^^^^^^^^^^^^^^^
   |
   = 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>`

error[E0055]: reached the recursion limit while auto-dereferencing `MySmartPtr<Content>`
##[error]  --> /checkout/tests/ui/self/arbitrary_self_type_infinite_recursion.rs:21:5
   |
LL |   p.method();

For more information how to resolve CI failures of this job, visit this link.

[ShaddyDC]

Thanks a lot for your comments, @RalfJung!

Has this been MCP'd / discussed on a team level before? The tracking issue does not seem to contain any such discussion. What motivated you to propose this change, out of the blue, as your first PR for Rust?

I am not aware of any previous discussion on this issue. I was talking with @dingxiangfei2009 about how I was interested in contributing to the language, and he suggested that this might be a good first issue to start on. The point of this PR is not to land right away but to start a discussion. Hence the "Proposal".

Note that generally we expect PR summaries to be written by the PR author. LLMs tend to generate incorrect and/or useless summaries. Your summary seems to contain factual mistakes, making it likely that you copied it without fact-checking it yourself. Please do not do that, it is disrespectful of maintainer's time.

My apologies, while I have used LLMs for parts of the PR description, the statements you mention and the factual mistakes you call out are explicitly mine and written by me. I honestly didn't expect anybody but Xiang to look at it yet, so I thought we could discuss how we want to move this forward and I could iterate on the description over the next couple of days.
I have now turned this into a draft as it should have been to begin with. Does that seem fair to you or would you prefer I close this until it is in a more ready state?