This is a tracking issue for work on pin ergonomics.
The feature gate for the issue is #![feature(pin_ergonomics)].
Design sketch
The basic pin projection rules that we're working toward are:
Alternative B:
- If
T: Unpin, &pin mut T and &mut T coerce to each other.
- If a
struct, enum, or union(?) defining a type T is annotated with #[pin_v2] (todo bikeshedding), then:
- Projection of
&pin mut T to &pin mut T.U is allowed.
- If
T: Drop , the Drop impl must use fn drop(&pin mut self).
- No manual impls of
Unpin are allowed on T.
- The user must ensure that, given a pinned reference to
T, the pinning contract is upheld for all ?Unpin fields of T.
(The rules apply likewise for &pin const T.)
Beyond pin projection, the basic overall idea of pin ergonomics is that &pin mut T (and &pin const T) should be integrated in the same sense as &mut T, in that reborrowing works, autoref works, corresponding binding modes exist, and that the borrow checker will track and ensure that once a &pin mut T is taken (even if no longer live) that we can't later get a &mut T or move T.
Alternative A
The original proposal, now labeled Alternative A, was:
- If
T: Unpin, &pin mut T and &mut T coerce to each other.
- If
T: Drop + !Unpin, require the Drop impl for T to use fn drop(&pin mut self).
- Projection of
&pin mut T to &pin mut T.U is allowed if either T: !Unpin or U: Unpin.
These rules are factored differently (using coercions (see here) and the fact that we haven't stabilized negative impls yet), but have the same effect as the rules in Niko's otherwise similar MinPin proposal.
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
Unresolved Questions
- Apparently this gives special semantics to the
Unpin trait (at least, the compiler uses is_unpin checks in &pin handling). That is a safe trait and hence cannot be deeply semantically meaningful. Is this coherent?
Related
TODO.
cc @eholk @rust-lang/lang
This is a tracking issue for work on pin ergonomics.
The feature gate for the issue is
#![feature(pin_ergonomics)].Design sketch
The basic pin projection rules that we're working toward are:
Alternative B:
T: Unpin,&pin mut Tand&mut Tcoerce to each other.struct,enum, orunion(?) defining a typeTis annotated with#[pin_v2](todo bikeshedding), then:&pin mut Tto&pin mut T.Uis allowed.T: Drop, theDropimpl must usefn drop(&pin mut self).Unpinare allowed onT.T, the pinning contract is upheld for all?Unpinfields ofT.(The rules apply likewise for
&pin const T.)Beyond pin projection, the basic overall idea of pin ergonomics is that
&pin mut T(and&pin const T) should be integrated in the same sense as&mut T, in that reborrowing works, autoref works, corresponding binding modes exist, and that the borrow checker will track and ensure that once a&pin mut Tis taken (even if no longer live) that we can't later get a&mut Tor moveT.Alternative A
The original proposal, now labeled Alternative A, was:
T: Unpin,&pin mut Tand&mut Tcoerce to each other.T: Drop + !Unpin, require theDropimpl forTto usefn drop(&pin mut self).&pin mut Tto&pin mut T.Uis allowed if eitherT: !UnpinorU: Unpin.These rules are factored differently (using coercions (see here) and the fact that we haven't stabilized negative impls yet), but have the same effect as the rules in Niko's otherwise similar MinPin proposal.
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
&pin const/&pin mutconstructor syntax in nightly.&pin const/&pin muttype syntax in nightly.&pin (mut|const) Ttype position sugar #130635&pin const self/&pin mut selfargument syntax in nightly.&pin const selfand&pin mut selfsugars #135733&pin mut|const T#139751fn drop(&pin mut self).fn drop(&pin mut self)whenT: Drop + !Unpin.&pin (mut|const) Tand&(mut) TwhenT: Unpin.ForceUnpin<T>type.PinAPI.Unresolved Questions
Unpintrait (at least, the compiler usesis_unpinchecks in&pinhandling). That is a safe trait and hence cannot be deeply semantically meaningful. Is this coherent?Related
TODO.
cc @eholk @rust-lang/lang