Implement Read and Write on Arc<TcpStream> and Arc<UnixStream>. - #134190
nmathewson wants to merge 2 commits into
Conversation
By analogy to rust-lang#94748, this change makes `Arc<TcpStream>` implement these traits that are already implemented on `&TcpStream`.
By analogy to rust-lang#94748, this change makes `Arc<UnixStream>` implement these traits that are already implemented on `&UnixStream`.
|
r? @Noratrieb rustbot has assigned @Noratrieb. Use |
|
Thank you for the PR! This PR contains a public library API change, which should follow the proper process of creating an ACP first: https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html |
|
Okay, ACP at rust-lang/libs-team#504. Let's see how they like it! |
|
☔ The latest upstream changes (presumably #136572) made this pull request unmergeable. Please resolve the merge conflicts. |
…ref, r=jhpratt Generalize IO Traits for `Arc<T>` where `&T: IoTrait` ACP: rust-lang/libs-team#755 Tracking issue: rust-lang#154046 Related: rust-lang#94744 ## Description After experimenting with rust-lang#155625, I noticed `Seek` and `SeekFrom` can almost be moved to `core::io`. Unfortunately, the implementation of `Seek` for `Arc<File>` is a blocker for such a move, since `Arc` is not a fundamental type. This PR attempts to resolve this potential blocker by replacing the implementation with a more general alternative. An internal trait `IoHandle` has been added which types can implement to opt-in to `Read`/`Write`/`Seek` implementations for `Arc<Self>` as long as `&Self` implements said trait. Note that `BufRead` is excluded as the signature for `fill_buf` would require returning from a temporary. Since this "blanket" implementation only applies to a single type which already implements the same traits, I believe this should have no user-facing impact. If this PR was merged, rust-lang#134190 could be replaced with a 2 line PR: ```rust impl IoHandle for TcpStream {} impl IoHandle for UnixStream {} ``` Likewise for any other types, a table of which can be found [here](rust-lang/libs-team#504 (comment)). This is out of scope for this PR to avoid the need for an ACP. --- ## Notes * See [this comment](rust-lang#154046 (comment)) for further details. * No AI tooling of any kind was used during the creation of this PR.
Rollup merge of #155684 - bushrat011899:blanket_io_seek_for_ref, r=jhpratt Generalize IO Traits for `Arc<T>` where `&T: IoTrait` ACP: rust-lang/libs-team#755 Tracking issue: #154046 Related: #94744 ## Description After experimenting with #155625, I noticed `Seek` and `SeekFrom` can almost be moved to `core::io`. Unfortunately, the implementation of `Seek` for `Arc<File>` is a blocker for such a move, since `Arc` is not a fundamental type. This PR attempts to resolve this potential blocker by replacing the implementation with a more general alternative. An internal trait `IoHandle` has been added which types can implement to opt-in to `Read`/`Write`/`Seek` implementations for `Arc<Self>` as long as `&Self` implements said trait. Note that `BufRead` is excluded as the signature for `fill_buf` would require returning from a temporary. Since this "blanket" implementation only applies to a single type which already implements the same traits, I believe this should have no user-facing impact. If this PR was merged, #134190 could be replaced with a 2 line PR: ```rust impl IoHandle for TcpStream {} impl IoHandle for UnixStream {} ``` Likewise for any other types, a table of which can be found [here](rust-lang/libs-team#504 (comment)). This is out of scope for this PR to avoid the need for an ACP. --- ## Notes * See [this comment](#154046 (comment)) for further details. * No AI tooling of any kind was used during the creation of this PR.
…pratt Generalize IO Traits for `Arc<T>` where `&T: IoTrait` ACP: rust-lang/libs-team#755 Tracking issue: rust-lang/rust#154046 Related: rust-lang/rust#94744 ## Description After experimenting with rust-lang/rust#155625, I noticed `Seek` and `SeekFrom` can almost be moved to `core::io`. Unfortunately, the implementation of `Seek` for `Arc<File>` is a blocker for such a move, since `Arc` is not a fundamental type. This PR attempts to resolve this potential blocker by replacing the implementation with a more general alternative. An internal trait `IoHandle` has been added which types can implement to opt-in to `Read`/`Write`/`Seek` implementations for `Arc<Self>` as long as `&Self` implements said trait. Note that `BufRead` is excluded as the signature for `fill_buf` would require returning from a temporary. Since this "blanket" implementation only applies to a single type which already implements the same traits, I believe this should have no user-facing impact. If this PR was merged, rust-lang/rust#134190 could be replaced with a 2 line PR: ```rust impl IoHandle for TcpStream {} impl IoHandle for UnixStream {} ``` Likewise for any other types, a table of which can be found [here](rust-lang/libs-team#504 (comment)). This is out of scope for this PR to avoid the need for an ACP. --- ## Notes * See [this comment](rust-lang/rust#154046 (comment)) for further details. * No AI tooling of any kind was used during the creation of this PR.
|
Based upon the fact that this is relatively trivial, has merge conflicts, and has an active ACP, I'm just going to close this for now. We do want to get through the ACP backlog soon and so hopefully this won't be left hanging too long, but I don't think it's necessarily helpful to keep this PR open in the meantime. Please do feel free to add more comments on the ACP if you've had any new thoughts in the past two years. |
By analogy to #94748, this PR makes
Arc<TcpStream>andArc<UnixStream>implementReadandWrite, which are already implemented on&TcpStreamand&UnixStream.This is my first non-documentation patch on the library; it's quite possible that I have gotten something wrong, especially surrounding the
#[stable]attribute.CC #53835
CC #94744