Error is crippled

[whitequark]

Specifically, this part is the problem:

     pub fn new<E>(kind: ErrorKind, error: E) -> Error
-        where E: Into<Box<error::Error+Send+Sync>>
+        where E: Into<String>

This means I cannot use any nonstandard I/O errors unless I'm willing to flatten them to a string. Currently, I have fifteen or so errors I get from lwip, and I would rather like to keep them as a enum.

[whitequark]

Oh, and of course this makes core_io not a strict subset of std::io, which IMO is a grave mistake.

[whitequark]

OK, I see now that error::Error cannot be moved from std into core (via rust-lang/rust#33149); perhaps a core_error crate could be made instead?

[jethrogb]

You found out why there is no std::Error. The "crippled" Error suits my purposes at this time, but if you want to build core_error following this design I'd be happy to use it here and endorse it.

[whitequark]

Ack. I will do so.

[Ericson2314]

I came here to open a new issue, but I guess I might as well hijack this one.

@Tobba and I wrote https://github.com/QuiltOS/core-io because we were deeply disappointed that the team went back on adding associated error types when Read/Write were stabilized. It was our opinion their ergonomics concerns were overblown cause their initial prototype was architected poorly, so we set out prove our case with that library.

As @whitequark notes in BurntSushi/byteorder#51 (comment), our library is missing functionality---this is not intentional but because we wrote our library manually and thus are always playing catch-up. Your automated method is better---perhaps the associated error type could be added as a patch on top whose application is enabled with a feature (off by default)?

[whitequark]

Why not just always add it? core_error would be a tiny crate.

My main concern here is #2, since unless I find a way to fix that, this crate would be useless to me. I have some time allocated to fixing upstream issues but it will be maybe in a month from now.