-
Notifications
You must be signed in to change notification settings - Fork 13.7k
arbitrary_self_types: Split the Autoderef chain #146095
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
arbitrary_self_types: Split the Autoderef chain #146095
Conversation
This PR changes a file inside |
This comment has been minimized.
This comment has been minimized.
bef5ba5
to
f3e8785
Compare
This comment has been minimized.
This comment has been minimized.
f3e8785
to
31788b7
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@rustbot label +F-arbitrary_self_types |
Receiver chain has been an extension of Deref chain, but the consequence has been questioned as this would admit method signatures that are deemed dubious. It is also debatable that Receiver trait which determines applicable `Self` type should have anything to do with dereference operation in general. This patch separate the two traits and isolate their use in the language. This means that in method probing, we will chase down a Deref chain for an applicable type for the variable `self`, from which we additionally chase down a Receiver chain for an applicable `Self` type from a list of methods that accepts one of these possible types of `self`.
31788b7
to
1a2dbf8
Compare
The Miri subtree was changed cc @rust-lang/miri Some changes occurred in compiler/rustc_codegen_gcc |
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
The job Click to see the possible cause of the failure (guessed by this bot)
|
Is this waiting on discussion and a decision from the lang team? |
@jackh726 Sorry I was not very clear. Indeed it would need a lang team discussion. To support the discussion, I am writing a report to describe what changes this would bring to the feature. |
Receiver chain has been an extension of Deref chain, but the consequence has been questioned as this would admit method signatures that are deemed dubious.
It is also debatable that Receiver trait which determines applicable
Self
type should have anything to do with dereference operation in general.This patch separate the two traits and isolate their use in the language. This means that in method probing, we will chase down a Deref chain for an applicable type for the variable
self
, from which we additionally chase down a Receiver chain for an applicableSelf
type from a list of methods that accepts one of these possible types ofself
.To facilitate discussion, we can use the Zulip thread #t-lang > Consequences of making Deref a subtrait of Receiver.
Pending items
arbitrary_self_types
gate again.