Error type

[AerialX]

Thoughts/comments on this approach?

[posborne]

Thanks for the PR @AerialX. Initially, I like this approach. I'll take a deeper look later tonight.

[posborne]

I'm wondering if there should be any additional traits required on this type. Nothing strikes me as really being worth requiring, so I think this is fine.

[AerialX]

I tried requiring std::error::Error but then found out nix::Error didn't impl it. I plan on addressing that in its own PR. fmt::Debug wouldn't be too bad to require, since Result::unwrap needs it.

[posborne]

The other thing that could have an impact is if we want to support no_std so devices could be used, for instance, in something like zinc. In that case, traits out of std (such as Debug) pose a problem.

[AerialX]

That's fair! Debug is in core though, only Error is in std (and it really shouldn't be, but...)

[posborne]

Overall, I think I like this. Do you know of any other projects making use of this pattern in a similar fashion? I searched around rust itself and found some instances that are somewhat similar but not quite the same. I would be curious to know if this approach has been taken with some success in the past?

[AerialX]

I'm under the impression than an Error associated type is pretty standard, I'd probably need to dig to find real examples though. The alternatives aren't great: enums that try to predict what's needed, io::Error or boxed Error trait objects, etc. Ensuring that the type impls error::Error and perhaps Into<io::Error> is usually a good way to ensure it meshes well into other libraries and code.

[posborne]

Ok, this looks like a great start. I'm going to merge and we can consider adding additional requirements on the Error types in other PRs.

[posborne]

Noticed that upstream implementation of Error has landed in nix upstream: nix-rust/nix#199