I added these two links to the error handling item:
- Why can't I `impl<E> From<E> for EzError where E: StdError + Send`?
- https://github.com/rust-lang/rust/issues/35943
But basically what I want to do is take the in-tree Error trait and put it in its own crate, name it Error2 perhaps, then create various crates around it that prove it can support all the patterns one might want, some of which are discussed in the linked threads, some of which are just notions in my head that may be lost already. The end result I want though is that other people can write support crates that allow the easiest-possible error handling solutions for newbies and those that don’t want to think hard about it. Potential requirements: it is possible to define an error type in one crate, and reuse it conveniently in other crates; don’t need to define a local error type or variants, but can reuse other crates error types; don’t need to define any conversions to support ? (i.e. box everything); preserve the cause chain with minimal work (ala error-chain).
Then see if its possible to create easy conversions between Error and Error2 so that Error2 can be viable without merging into std as Error and breaking the world.
Fixed the poisoning link.