Require that errors are Send/Sync/'static.

[withoutboats]

Currently, they are not Sync because they contain a non-Sync trait
object. This is a breaking change.

The decision to make errors Send but not Sync was made in #110. We
believe that decision was a mistake, because it perpetuates a !Sync
restriction on all users even if their errors are, in fact, Sync.
Instead, users who need errors that are !Sync should use
synchronization when transforming their errors into error-chain
errors.

cc @aturon

[bvinc]

I support this PR. Here are some arguments I have for supporting it.

• io::Error is designed to wrap other errors. This is required if anyone wants to implement Read or Write and have meaningful errors. io::Error has decided that all errors that it wraps must be Sync. This means that error-chain is fighting against the standard library.
• error-chain is recursively making everyone's errors !Sync when they don't need to be.
• If someone wants to make their errors Sync, but one of the causal errors is !Sync because it uses error-chain, they can't implement the std::error::Error trait's cause method. The cause method returns a reference, which it can't do if the causal error is behind a Mutex.
• If anyone rightfully has !Sync data inside of their error, it would seem pretty easy to add synchronization without affecting anything else.
• If this isn't fixed, I would think that any library that uses error-chain should rightfully get an issue reported that their error isn't Sync when it should be. I would think it would hurt adoption of error-chain in the long run.

[aturon]

cc @rust-lang-nursery/libs I'd like to merge this PR, any objections?

[KodrAus]

I'm in favour of this too 👍

[alexcrichton]

I have no ticky box to check off :(

Sounds great!

[luser]

If everyone is in favor, can this be merged? We'll still have to get crates that use error-chain updated to the new version, but it will definitely make interop between error-chain and failure crates much simpler.

[aturon]

@withoutboats, can you merge and publish?

[withoutboats]

Will do this week!

[aidanhs]

@withoutboats I guess you got a bit delayed? 😄

[L-as]

I'd really love to see this merged.

[Terkwood]

Ooo

[pietroalbini]

Ping @withoutboats :)

[Kixunil]

Did you fall into a black hole? I need this. :(

[AndyGauge]

I don't believe we have the support required to add features to this library. We are currently only maintaining compatibility with rustc and not adding features.

[Kixunil]

Does that mean error-chain is deprecated or you don't have the resources? Frankly, this change is so important to me that I'm willing to resolve merge conflict if someone is willing to review it and hit "Merge" button.

[AndyGauge]

I'm most concerned with the breaking change adversely affecting users of the library. I guess I may be taking too measured an approach.

[Kixunil]

Ah, good point. Though the consensus was that this is wanted, so it may be worth it? It'd definitely need to be semver-breaking, so that people update at their own pace.

[luser]

I don't think I'm alone in my assessment that error-chain, while a useful exploration of the design space, is out of date with regards to the evolution of Rust error handling practices. If you're still actively using this crate you should consider replacing it with one of several newer crates that are actively maintained. This blog post from last year has a survey of several options, including some words on error-chain itself.

[AndyGauge]

error-chain was a pioneer in this space, and it was the work done here that created the rust primitives (that story is probably longer, more nuanced, and only influenced by error-chain). Now, it left to show why rust needed an error-handling library. Now enums and simple macros can provide the combination of error types; a library is less important.

[Kixunil]

Right, the change would have to be breaking anyway, so might as well change the library.

[john-sharratt]

Made a new pull request that adds 'Sync' via a feature toggle for backwards compatibility
#300