-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Consider changing io::Error to use Arc so it can implement Clone #24135
Comments
/cc @alexcrichton |
@kballard @alexcrichton it seems like the change was done, but that |
The choice to use |
damn, a clonable io::Error would be really nice for me right now 😢 |
Normally I would just leave a 👍 here, but it's been a year since the last comment and I've bumped up against this several times in the past few weeks. Would an RFC be appropriate here to move things along, or is further discussion required? (If so, in what venue?) |
@alexcrichton: @spinda and others have brought this issue up again, but no action or explanation has followed. Moreover, this issue has only one tag. Are you the person to triage or otherwise take action on this, or perhaps someone else? |
I would prefer for this to go through the RFC process. Most importantly for the RFC, one thing that hasn't been discussed so far is what are some of the uses cases where cloning an io::Error is the best solution. The RFC would need to provide some concrete situations from real code where not being able to clone an io::Error causes problems, and justify why cloning an io::Error is the best solution to those problems. Second, a discussion of what implications this would have for performance. In my opinion this is not critical but it may help avoid derailing the discussion with guesses about Arc performance. |
For the record, I needed cloneable fn get_foo(&self) -> Result<Foo, Err> {
self.cached.clone()
} I've worked around that by storing |
I just wanted to chime in here. Many use cases can indeed work around this issue, but I'm currently hitting one that's pretty much insoluable as far as I can see. I have a stream of My current workaround is to simply not send |
@NoraCodes Can you replace the |
Another use case: I was trying to reimplement a slice of impl Child {
pub async fn wait(&mut self) -> std::io::Result<ExitStatus>;
} Notably, you should be able to call this multiple times, (though not in parallel) and it should return the same result - including any error. Doing this relatively safely (given you need to call FFI at a minimum) is quite tricky: for clarity the issue is the same in the simplest option: to The ideal here is to model
and simply return the content of |
This is so that we can implement `Clone` for `Error` in a following commit w/o ending up tranforming all I/O errors to generic string errors during cloning (`std::io::Error` doesn't implement `Clone`[1]). We still keep `Io` variant around for backwards-compat but we deprecate it and don't return errors with that variant for any of our API anymore. [1]: rust-lang/rust#24135
This is so that we can implement `Clone` for `Error` in a following commit w/o ending up tranforming all I/O errors to generic string errors during cloning (`std::io::Error` doesn't implement `Clone`[1]). We still keep `Io` variant around for backwards-compat but we deprecate it and don't return errors with that variant for any of our API anymore. [1]: rust-lang/rust#24135
I have a The best I can think of is mapping the errors to Is it possible to fix this without breaking the API? |
io::Error
can't implementClone
right now because it uses a trait object internally for custom errors. With #24133 adding theSync
bound, it becomes possible to putio::Error
inArc
. But it would still be nice to be able toClone
it again, which could be accomplished by changing the privateBox<Custom>
field toArc<Custom>
instead.The text was updated successfully, but these errors were encountered: