Partially seal error types.

[partim]

This PR looks at all the error types and splits them into meaningful error information, which will be available as enum variants, and internals, which will be hidden away behind opaque structs. For the former case, we will still use enums directly rather than have error kind enums. These will not be non-exhaustive since they should really cover all possible cases and exhaustive matching should work.

This is a breaking change.

Fixes #141

[ximon18]

@partim: I get the point of this change, and understand how the hiding works when an enum variant has a public inner value but whose construction is private and thus only possible from within the crate code itself, and that for variants that can't be acted upon but merely need to be communicated handle this via a Display impl on the private type.

What I don't get is why things like pub struct CharStrError; have become pub struct CharStrError(());- what value does that inner unit type add?

[partim]

What I don't get is why things like pub struct CharStrError; have become pub struct CharStrError(());- what value does that inner unit type add?

It blocks users from creating values other than through calling functions that return them. The reason for this is that it allows us later to change the type definition without it being a breaking change. (E.g., we might want to also use an inner enum.)

[ximon18]

What I don't get is why things like pub struct CharStrError; have become pub struct CharStrError(());- what value does that inner unit type add?

It blocks users from creating values other than through calling functions that return them. The reason for this is that it allows us later to change the type definition without it being a breaking change. (E.g., we might want to also use an inner enum.)

Ah because that inner unit field is private, which is hard to see at a glance when using a unit struct. Thanks.