Error is crippled
whitequark opened this issue · 6 comments
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.
Oh, and of course this makes core_io not a strict subset of std::io, which IMO is a grave mistake.
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?
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.
Ack. I will do so.
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)?
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.