Consider changing io::Error to use Arc so it can implement Clone

[lilyball]

io::Error can't implement Clone right now because it uses a trait object internally for custom errors. With #24133 adding the Sync bound, it becomes possible to put io::Error in Arc. But it would still be nice to be able to Clone it again, which could be accomplished by changing the private Box<Custom> field to Arc<Custom> instead.

[lilyball]

/cc @alexcrichton

[sbstp]

@kballard @alexcrichton it seems like the change was done, but that io::Error still doesn't implement clone.Was it forgotten?

[alexcrichton]

The choice to use Arc was intentionally left out to take the more conservative route to start out. Some time has passed, though, and it could perhaps be re-evaluated again.

[flying-sheep]

damn, a clonable io::Error would be really nice for me right now 😢

[spinda]

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?)

[sanmai-NL]

@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?

[dtolnay]

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.