-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Tracking Issue for pin_deref_mut
#86918
Comments
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Are there any remaining blockers on this? It's a pretty useful function for blanket impls for traits with poll methods (e.g. Future already uses it in its |
Not that I know of — given it touches the |
Currently this method is located in its own solitary impl block: impl<'a, Ptr: DerefMut> Pin<&'a mut Pin<Ptr>> {
pub fn as_deref_mut(self) -> Pin<&'a mut Ptr::Target>;
} I'd like to consider changing it to: impl<Ptr> Pin<Ptr> {
pub fn as_deref_mut(self: Pin<&mut Pin<Ptr>>) -> Pin<&mut Ptr::Target>
where
Ptr: DerefMut;
} Some advantages:
impl<Ptr> Pin<Ptr> {
pub fn as_ref(&self) -> Pin<&Ptr::Target>
where
Ptr: Deref;
pub fn as_mut(&mut self) -> Pin<&mut Ptr::Target>
where
Ptr: DerefMut;
} |
Any concern blocks this from stablization? |
@dtolnay I agree — that is better 👍 |
…ature, r=dtolnay Put Pin::as_deref_mut in impl Pin<Ptr> / rearrange Pin methods Tracking issue: rust-lang#86918 Based on the suggestion in rust-lang#86918 (comment) > Some advantages: > > * Synergy with the existing `as_ref` and `as_mut` signatures (stable since Rust 1.33) > > * Lifetime elision reduces noise in the signature > > * Turbofish less verbose: `Pin::<&mut T>::as_deref_mut` vs `Pin::<&mut Pin<&mut T>>::as_deref_mut` The comment seemed to imply that `Pin::as_ref` and `Pin::as_mut` already share an impl block, which they don't. So, I rearranged it so that they do, and we can see which looks better in the docs. <details><summary><b>Docs screenshots</b></summary> Current nightly: ![image](https://github.com/user-attachments/assets/b432cb82-8f4b-48ae-bafc-2fe49d0ad48c) `Pin::as_deref_mut` moved into the same block as `as_mut`: ![image](https://github.com/user-attachments/assets/f9b35722-6a88-4465-ad1c-28d8e91902ac) `Pin::as_ref`, `as_mut`, and `as_deref_mut` all in the same block: ![image](https://github.com/user-attachments/assets/9a1b2bf0-70a6-4751-b13f-390f1d575244) </details> I think I like the last one the most; obviously I'm biased since I'm the one who rearranged it, but it doesn't make sense to me to have `as_ref` methods split up by an `into_inner` method. r? dtolnay
…ature, r=dtolnay Put Pin::as_deref_mut in impl Pin<Ptr> / rearrange Pin methods Tracking issue: rust-lang#86918 Based on the suggestion in rust-lang#86918 (comment) > Some advantages: > > * Synergy with the existing `as_ref` and `as_mut` signatures (stable since Rust 1.33) > > * Lifetime elision reduces noise in the signature > > * Turbofish less verbose: `Pin::<&mut T>::as_deref_mut` vs `Pin::<&mut Pin<&mut T>>::as_deref_mut` The comment seemed to imply that `Pin::as_ref` and `Pin::as_mut` already share an impl block, which they don't. So, I rearranged it so that they do, and we can see which looks better in the docs. <details><summary><b>Docs screenshots</b></summary> Current nightly: ![image](https://github.com/user-attachments/assets/b432cb82-8f4b-48ae-bafc-2fe49d0ad48c) `Pin::as_deref_mut` moved into the same block as `as_mut`: ![image](https://github.com/user-attachments/assets/f9b35722-6a88-4465-ad1c-28d8e91902ac) `Pin::as_ref`, `as_mut`, and `as_deref_mut` all in the same block: ![image](https://github.com/user-attachments/assets/9a1b2bf0-70a6-4751-b13f-390f1d575244) </details> I think I like the last one the most; obviously I'm biased since I'm the one who rearranged it, but it doesn't make sense to me to have `as_ref` methods split up by an `into_inner` method. r? dtolnay
…ature, r=dtolnay Put Pin::as_deref_mut in impl Pin<Ptr> / rearrange Pin methods Tracking issue: rust-lang#86918 Based on the suggestion in rust-lang#86918 (comment) > Some advantages: > > * Synergy with the existing `as_ref` and `as_mut` signatures (stable since Rust 1.33) > > * Lifetime elision reduces noise in the signature > > * Turbofish less verbose: `Pin::<&mut T>::as_deref_mut` vs `Pin::<&mut Pin<&mut T>>::as_deref_mut` The comment seemed to imply that `Pin::as_ref` and `Pin::as_mut` already share an impl block, which they don't. So, I rearranged it so that they do, and we can see which looks better in the docs. <details><summary><b>Docs screenshots</b></summary> Current nightly: ![image](https://github.com/user-attachments/assets/b432cb82-8f4b-48ae-bafc-2fe49d0ad48c) `Pin::as_deref_mut` moved into the same block as `as_mut`: ![image](https://github.com/user-attachments/assets/f9b35722-6a88-4465-ad1c-28d8e91902ac) `Pin::as_ref`, `as_mut`, and `as_deref_mut` all in the same block: ![image](https://github.com/user-attachments/assets/9a1b2bf0-70a6-4751-b13f-390f1d575244) </details> I think I like the last one the most; obviously I'm biased since I'm the one who rearranged it, but it doesn't make sense to me to have `as_ref` methods split up by an `into_inner` method. r? dtolnay
…ature, r=dtolnay Put Pin::as_deref_mut in impl Pin<Ptr> / rearrange Pin methods Tracking issue: rust-lang#86918 Based on the suggestion in rust-lang#86918 (comment) > Some advantages: > > * Synergy with the existing `as_ref` and `as_mut` signatures (stable since Rust 1.33) > > * Lifetime elision reduces noise in the signature > > * Turbofish less verbose: `Pin::<&mut T>::as_deref_mut` vs `Pin::<&mut Pin<&mut T>>::as_deref_mut` The comment seemed to imply that `Pin::as_ref` and `Pin::as_mut` already share an impl block, which they don't. So, I rearranged it so that they do, and we can see which looks better in the docs. <details><summary><b>Docs screenshots</b></summary> Current nightly: ![image](https://github.com/user-attachments/assets/b432cb82-8f4b-48ae-bafc-2fe49d0ad48c) `Pin::as_deref_mut` moved into the same block as `as_mut`: ![image](https://github.com/user-attachments/assets/f9b35722-6a88-4465-ad1c-28d8e91902ac) `Pin::as_ref`, `as_mut`, and `as_deref_mut` all in the same block: ![image](https://github.com/user-attachments/assets/9a1b2bf0-70a6-4751-b13f-390f1d575244) </details> I think I like the last one the most; obviously I'm biased since I'm the one who rearranged it, but it doesn't make sense to me to have `as_ref` methods split up by an `into_inner` method. r? dtolnay
…ature, r=dtolnay Put Pin::as_deref_mut in impl Pin<Ptr> / rearrange Pin methods Tracking issue: rust-lang#86918 Based on the suggestion in rust-lang#86918 (comment) > Some advantages: > > * Synergy with the existing `as_ref` and `as_mut` signatures (stable since Rust 1.33) > > * Lifetime elision reduces noise in the signature > > * Turbofish less verbose: `Pin::<&mut T>::as_deref_mut` vs `Pin::<&mut Pin<&mut T>>::as_deref_mut` The comment seemed to imply that `Pin::as_ref` and `Pin::as_mut` already share an impl block, which they don't. So, I rearranged it so that they do, and we can see which looks better in the docs. <details><summary><b>Docs screenshots</b></summary> Current nightly: ![image](https://github.com/user-attachments/assets/b432cb82-8f4b-48ae-bafc-2fe49d0ad48c) `Pin::as_deref_mut` moved into the same block as `as_mut`: ![image](https://github.com/user-attachments/assets/f9b35722-6a88-4465-ad1c-28d8e91902ac) `Pin::as_ref`, `as_mut`, and `as_deref_mut` all in the same block: ![image](https://github.com/user-attachments/assets/9a1b2bf0-70a6-4751-b13f-390f1d575244) </details> I think I like the last one the most; obviously I'm biased since I'm the one who rearranged it, but it doesn't make sense to me to have `as_ref` methods split up by an `into_inner` method. r? dtolnay
…ature, r=dtolnay Put Pin::as_deref_mut in impl Pin<Ptr> / rearrange Pin methods Tracking issue: rust-lang#86918 Based on the suggestion in rust-lang#86918 (comment) > Some advantages: > > * Synergy with the existing `as_ref` and `as_mut` signatures (stable since Rust 1.33) > > * Lifetime elision reduces noise in the signature > > * Turbofish less verbose: `Pin::<&mut T>::as_deref_mut` vs `Pin::<&mut Pin<&mut T>>::as_deref_mut` The comment seemed to imply that `Pin::as_ref` and `Pin::as_mut` already share an impl block, which they don't. So, I rearranged it so that they do, and we can see which looks better in the docs. <details><summary><b>Docs screenshots</b></summary> Current nightly: ![image](https://github.com/user-attachments/assets/b432cb82-8f4b-48ae-bafc-2fe49d0ad48c) `Pin::as_deref_mut` moved into the same block as `as_mut`: ![image](https://github.com/user-attachments/assets/f9b35722-6a88-4465-ad1c-28d8e91902ac) `Pin::as_ref`, `as_mut`, and `as_deref_mut` all in the same block: ![image](https://github.com/user-attachments/assets/9a1b2bf0-70a6-4751-b13f-390f1d575244) </details> I think I like the last one the most; obviously I'm biased since I'm the one who rearranged it, but it doesn't make sense to me to have `as_ref` methods split up by an `into_inner` method. r? dtolnay
Rollup merge of rust-lang#129449 - coolreader18:pin-as_deref_mut-signature, r=dtolnay Put Pin::as_deref_mut in impl Pin<Ptr> / rearrange Pin methods Tracking issue: rust-lang#86918 Based on the suggestion in rust-lang#86918 (comment) > Some advantages: > > * Synergy with the existing `as_ref` and `as_mut` signatures (stable since Rust 1.33) > > * Lifetime elision reduces noise in the signature > > * Turbofish less verbose: `Pin::<&mut T>::as_deref_mut` vs `Pin::<&mut Pin<&mut T>>::as_deref_mut` The comment seemed to imply that `Pin::as_ref` and `Pin::as_mut` already share an impl block, which they don't. So, I rearranged it so that they do, and we can see which looks better in the docs. <details><summary><b>Docs screenshots</b></summary> Current nightly: ![image](https://github.com/user-attachments/assets/b432cb82-8f4b-48ae-bafc-2fe49d0ad48c) `Pin::as_deref_mut` moved into the same block as `as_mut`: ![image](https://github.com/user-attachments/assets/f9b35722-6a88-4465-ad1c-28d8e91902ac) `Pin::as_ref`, `as_mut`, and `as_deref_mut` all in the same block: ![image](https://github.com/user-attachments/assets/9a1b2bf0-70a6-4751-b13f-390f1d575244) </details> I think I like the last one the most; obviously I'm biased since I'm the one who rearranged it, but it doesn't make sense to me to have `as_ref` methods split up by an `into_inner` method. r? dtolnay
Would it be possible to start an FCP on this? |
@rust-lang/libs-api:
The use case arises in real-world code when you are implementing a trait that takes In tokio: In hyper: In futures: In actix: In libcore: rust/library/core/src/future/future.rs Lines 116 to 122 in bf662eb
rust/library/core/src/async_iter/async_iter.rs Lines 99 to 106 in bf662eb
|
Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
…f_mut, r=dtolnay Stabilize `Pin::as_deref_mut()` Tracking issue: rust-lang#86918 Stabilizing the following API: ```rust impl<Ptr: DerefMut> Pin<Ptr> { pub fn as_deref_mut(self: Pin<&mut Pin<Ptr>>) -> Pin<&mut Ptr::Target>; } ``` I know that an FCP has not been started yet, but this isn't a very complex stabilization, and I'm hoping this can motivate an FCP to *get* started - this has been pending for a while and it's a very useful function when writing Future impls. r? `@jonhoo`
…f_mut, r=dtolnay Stabilize `Pin::as_deref_mut()` Tracking issue: closes rust-lang#86918 Stabilizing the following API: ```rust impl<Ptr: DerefMut> Pin<Ptr> { pub fn as_deref_mut(self: Pin<&mut Pin<Ptr>>) -> Pin<&mut Ptr::Target>; } ``` I know that an FCP has not been started yet, but this isn't a very complex stabilization, and I'm hoping this can motivate an FCP to *get* started - this has been pending for a while and it's a very useful function when writing Future impls. r? `@jonhoo`
…mut, r=dtolnay Stabilize `Pin::as_deref_mut()` Tracking issue: closes rust-lang#86918 Stabilizing the following API: ```rust impl<Ptr: DerefMut> Pin<Ptr> { pub fn as_deref_mut(self: Pin<&mut Pin<Ptr>>) -> Pin<&mut Ptr::Target>; } ``` I know that an FCP has not been started yet, but this isn't a very complex stabilization, and I'm hoping this can motivate an FCP to *get* started - this has been pending for a while and it's a very useful function when writing Future impls. r? `@jonhoo`
…mut, r=dtolnay Stabilize `Pin::as_deref_mut()` Tracking issue: closes rust-lang#86918 Stabilizing the following API: ```rust impl<Ptr: DerefMut> Pin<Ptr> { pub fn as_deref_mut(self: Pin<&mut Pin<Ptr>>) -> Pin<&mut Ptr::Target>; } ``` I know that an FCP has not been started yet, but this isn't a very complex stabilization, and I'm hoping this can motivate an FCP to *get* started - this has been pending for a while and it's a very useful function when writing Future impls. r? `@jonhoo`
…f_mut, r=dtolnay Stabilize `Pin::as_deref_mut()` Tracking issue: closes rust-lang#86918 Stabilizing the following API: ```rust impl<Ptr: DerefMut> Pin<Ptr> { pub fn as_deref_mut(self: Pin<&mut Pin<Ptr>>) -> Pin<&mut Ptr::Target>; } ``` I know that an FCP has not been started yet, but this isn't a very complex stabilization, and I'm hoping this can motivate an FCP to *get* started - this has been pending for a while and it's a very useful function when writing Future impls. r? `@jonhoo`
Rollup merge of rust-lang#129424 - coolreader18:stabilize-pin_as_deref_mut, r=dtolnay Stabilize `Pin::as_deref_mut()` Tracking issue: closes rust-lang#86918 Stabilizing the following API: ```rust impl<Ptr: DerefMut> Pin<Ptr> { pub fn as_deref_mut(self: Pin<&mut Pin<Ptr>>) -> Pin<&mut Ptr::Target>; } ``` I know that an FCP has not been started yet, but this isn't a very complex stabilization, and I'm hoping this can motivate an FCP to *get* started - this has been pending for a while and it's a very useful function when writing Future impls. r? ``@jonhoo``
Feature gate:
#![feature(pin_deref_mut)]
This is a tracking issue for
Pin::as_deref_mut
.The feature adds the method
as_deref_mut
toPin
, which allow a safe transformation from aPin<&mut Pin<P>>
to aPin<&mut P::Target>
.Public API
Steps / History
Pin::as_deref_mut()
#129424Unresolved Questions
The text was updated successfully, but these errors were encountered: