-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Clarify semantics of File::try_clone()
#46578
Comments
Tagging P-medium at @Havvy 's request. |
Having an example where it shows this behaviour would also be helpful. E.g. try_clone the File, mutate the internal state in the clone, and then show that the original has also been mutated. Such as a file with contents "123456". Read to "3" in the clone, and then show that the next read of a character gets you "4". The semantics that a separate File can change the first one should also probably be mentioned in the struct level documentation, since that's quite important to know even if you never call the method yourself. |
This is very similar to #45536, if not a duplicate |
Not a dupe. #45536 is about what the error case is. This is about being more explicit about the shared cursor position in the success case. Very related though. |
I opened a PR for this: #47958 |
Clarify shared file handler behavior of File::try_clone. Fixes rust-lang#46578.
Clarify shared file handler behavior of File::try_clone. Fixes rust-lang#46578.
Clarify shared file handler behavior of File::try_clone. Fixes rust-lang#46578.
File::try_clone()
could be clearer about how the duplicated file cursors behave. It currently says:I think it could be much clearer about how reads, writes, and seeks will affect both handles.
The text was updated successfully, but these errors were encountered: