-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
Tracking issue for RFC 3519: arbitrary_self_types #44874
Copy link
Copy link
Open
Labels
B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.Blocker: Approved by a merged RFC but not yet implemented.B-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCF-arbitrary_self_types`#![feature(arbitrary_self_types)]``#![feature(arbitrary_self_types)]`S-tracking-needs-summaryStatus: It's hard to tell what's been done and what hasn't! Someone should do some investigation.Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation.S-types-deferredStatus: Identified as a valid potential future enhancement that is not currently being worked onStatus: Identified as a valid potential future enhancement that is not currently being worked onT-langRelevant to the language teamRelevant to the language teamT-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.Blocker: Approved by a merged RFC but not yet implemented.B-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCF-arbitrary_self_types`#![feature(arbitrary_self_types)]``#![feature(arbitrary_self_types)]`S-tracking-needs-summaryStatus: It's hard to tell what's been done and what hasn't! Someone should do some investigation.Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation.S-types-deferredStatus: Identified as a valid potential future enhancement that is not currently being worked onStatus: Identified as a valid potential future enhancement that is not currently being worked onT-langRelevant to the language teamRelevant to the language teamT-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
This is the tracking issue for RFC 3519: Arbitrary self types v2.
The feature gate for this issue is
#![feature(arbitrary_self_types)].About tracking issues
Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Current plan is:
arbitrary_self_types_pointersfeature gateReceivertrait -- currently being run through craterReceivertrait without it doing anything.Receivertrait, if thearbitrary_self_typesfeature is enabled. The main event.!Sizedcase and theNonNulletc. cases.DerefandReceivertraits should be decoupled (cc @dingxiangfei2009).Derefa subtrait ofReceiver.ptr_cast_add_auto_to_objectlint into hard error #136764Unresolved Questions
None.
Notable for Stabilization
Related
Implementation history
(Below follows content that predated the accepted Arbitrary Self Types v2 RFC.)
Details
Object Safety
See #27941 (comment)
Handling of inference variables
Calling a method on
*const _could now pick impls of the formBecause method dispatch wants to be "limited", this won't really work, and as with the existing situation on
&_we should be emitting an "the type of this value must be known in this context" error.This feels like fairly standard inference breakage, but we need to check the impact of this before proceeding.
Safe virtual raw pointer methods
e.g. this is UB, so we might want to force the call
<dyn Foo as Foo>::barto be unsafe somehow - e.g. by not allowingdyn Footo be object safe unlessbarwas anunsafe fnHowever, even today you could UB in safe code with
mem::size_of_val(foo)on the above code, so this might not be actually a problem.More information
There's no reason the
selfsyntax has to be restricted to&T,&mut TandBox<T>, we should allow for more types there, e.g.