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

[Stabilization] Stablize using some arbitrary self types defined in std #55786

Open
withoutboats opened this Issue Nov 8, 2018 · 9 comments

Comments

Projects
None yet
6 participants
@withoutboats
Contributor

withoutboats commented Nov 8, 2018

Feature name: arbitrary_self_types
Stabilization target: 1.32.0
Tracking issue: #44874
Related RFCs: rust-lang/rfcs#2362

This is a proposal to stabilize a subset of the arbitrary_self_types feature,
making it possible on stable to use valid "arbitrary" self types that have been
defined in the standard library, but not to define your own new self types.

Stabilized feature or APIs

Today, only the following types are allowed as self types unless the user uses
the arbitrary_self_types flag:

  • Self
  • &Self
  • &mut Self
  • Box<Self>

We've long desired to extend this set to all pointer types defined in std, and
(ideally) to arbitrary user defined pointer types. For quite a while now, the
ability to create user defined self types has existed on nightly under the
arbitrary_self_types flag; in this stabilization, we propose to stabilize the
extension of self types to all the relevant pointer types defined in std and
their compositions, while leaving the ability to create your own self types
unstable for now while we iterate on the exact requirements.

The new self types that will be enabled by this stabilization are:

  • *const Self
  • *mut Self
  • Rc<Self>
  • Arc<Self>
  • Pin<P> where P is another type in this set.
  • The composition of any members in this set (e.g. &Box<Self>,
    Pin<&mut Rc<Self>>).

Additionally, all of these receiver types except for Self are object safe, in
the sense that they can be used as the receivers of object-safe trait methods.

Object safety of raw pointer types

By making pointers object-safe, we have introduced an additional requirement on
raw pointers: a wide raw pointer must contain valid metadata, even if the
data pointer is null or dangling. That is, a *const dyn Trait must have
a metadata pointer pointing to a valid vtable for Trait.

As an alternative, we could possibly restrict this to only allowing raw
pointers as the receiver types for unsafe methods, and validity of the metadata
pointer would be an invariant the caller would be expected to uphold.

Non-Deref pointer types

Library defined pointer types can only be receiver types if they implement
Deref currently. This excludes certain std pointer types that don't implement
Deref, because they could be dangling:

  • NonNull<Self>
  • rc::Weak<Self>
  • sync::Weak<Self>

This stabilization is forward compatible with someday supporting these pointers
as receiver types as we continue to iterate on the requirements of defining
arbitrary self types.

Magic traits involved

It's worth noting that currently the implementation of this functionality
involves the intersection of several ops traits:

  • Deref - a self type must be deref, transitively targeting Self
  • CoerceUnsized
  • DispatchFromDyn - this and the previous are necessary for object safe
  • (potentially) Receiver - a private trait in std used to limit stabilization
    only to these std traits

The interaction of this feature with these traits is not made stable as a
part of this proposal. The traits listed that are still unstable remain
unstable. We still have flexibility to iterate on the exact requirements on
arbitrary self types so long as those requirements include all of the types I
have enumerated previously.

Implementation changes prior to stabilization

  • Receiver trait to limit stable self types to those defined in std
    (@mikeyhew is working on this)

  • Adjust documentation and diagnostics to note the additional valid
    receiver types defined in std, instead of only the 4 accepted today

Connected features and larger milestones

A trait making use of this feature is the Future trait, which is still
unstable under the futures_api feature:

trait Future {
    type Output;
    fn poll(self: Pin<&mut Self>, lw: &LocalWaker) -> Poll<Self::Output>;
}

Before we can stabilize this trait, we need to stabilize the ability to
implement traits using Pin<&mut Self> as a receiver type: hence, this
stabilization. Stabilizing the futures_api feature is a high priority because
it is a blocker for stabilizing the async/await syntax, which makes nonblocking
IO much more ergonomic for Rust.

cc @mikeyhew

@withoutboats withoutboats added the T-lang label Nov 8, 2018

@withoutboats

This comment has been minimized.

Contributor

withoutboats commented Nov 8, 2018

@rfcbot fcp merge

@rfcbot

This comment has been minimized.

rfcbot commented Nov 8, 2018

Team member @withoutboats has proposed to merge this. The next step is review by the rest of the tagged teams:

Concerns:

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@withoutboats

This comment has been minimized.

Contributor

withoutboats commented Nov 8, 2018

@rfcbot concern raw-pointers-metadata

I don't have a position, but the lang team should decide: shall we require that raw wide pointers (like *const dyn Trait) always have valid metadata, or shall we require that methods using raw pointers as the receiver type always be marked unsafe?

@withoutboats

This comment has been minimized.

Contributor

withoutboats commented Nov 8, 2018

We could also delay decisions about raw pointers by not stabilizing them now, they're the only potentially dangling method receivers in the stabilization set.

@kennytm

This comment has been minimized.

Member

kennytm commented Nov 8, 2018

Additionally, all of these receiver types except for Self are object safe

Do we need this exception given unsized rvalues (#48055)?

Deref - a self type must be deref, transitively targeting Self

The raw pointers don't implement Deref the trait though. Probably further justifying not stabilizing them.

@mikeyhew

This comment has been minimized.

Contributor

mikeyhew commented Nov 8, 2018

I'm just chiming in since I've been CC'd. I am for everything proposed, but understand that there may be some controversy about raw-pointer methods. I would be fine with excluding them for now and waiting for an RFC.

@joshtriplett

This comment has been minimized.

Member

joshtriplett commented Nov 8, 2018

I would also like to exclude raw pointer methods for now, and stabilize the rest.

@joshtriplett

This comment has been minimized.

Member

joshtriplett commented Nov 8, 2018

@rfcbot concern do-not-stabilize-raw-pointers

@Centril

This comment has been minimized.

Contributor

Centril commented Nov 8, 2018

I agree with @joshtriplett here re. raw pointers; I don't think sufficient justification is given for either approach mentioned so it is hard to determine what the right course of action is.

Tho I wonder a bit about process here... we haven't accepted any RFC to stabilize the rest either yet... is that OK?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment