Implement Read and Write on Arc<TcpStream> and Arc<UnixStream>.#134190
Open
nmathewson wants to merge 2 commits intorust-lang:mainfrom
Open
Implement Read and Write on Arc<TcpStream> and Arc<UnixStream>.#134190nmathewson wants to merge 2 commits intorust-lang:mainfrom
Read and Write on Arc<TcpStream> and Arc<UnixStream>.#134190nmathewson wants to merge 2 commits intorust-lang:mainfrom
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`.
Collaborator
|
r? @Noratrieb rustbot has assigned @Noratrieb. Use |
rustbot
added
O-unix
Member
|
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 |
rustbot
added
S-waiting-on-author
Contributor
Author
|
Okay, ACP at rust-lang/libs-team#504. Let's see how they like it! |
Collaborator
|
☔ The latest upstream changes (presumably #136572) made this pull request unmergeable. Please resolve the merge conflicts. |
LFS6502
added
the
S-waiting-on-ACP
Dylan-DPC
removed
the
S-waiting-on-author
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Apr 24, 2026
…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.
rust-timer
added a commit
that referenced
this pull request
Apr 24, 2026
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.
github-actions Bot
pushed a commit
to rust-lang/rustc-dev-guide
that referenced
this pull request
Apr 27, 2026
…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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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