0.11.0

[maciejhirsz]

Fixes #93

[dtolnay]

Isn't this a breaking change? If someone does a match on Error this breaks their code.

[maciejhirsz]

Good point.

[Mark-Simulacrum]

While we're making a breaking change, maybe update the Error enum to have a __Nonexhaustive variant to allow future extensibility?

[maciejhirsz]

@Mark-Simulacrum is this an advised best practice?

I think while this library is still in pre-1.0 state the occasional breaking change of this (microscopic) magnitude is quite okay, and post 1.0 I'd rather want to have the Error types set and solid.

[Mark-Simulacrum]

I know this is used in the stdlib, for example, so I'd say that yes--any enums that may gain new variants can/should have a variant marked for this purpose.

[meh]

@Mark-Simulacrum that's only for enums that you NEVER want to be fully exhausted, i.e. to always have a catch-all at the end, not for preventing breaking changes.

[Mark-Simulacrum]

@meh That's true. Though, to some extent, there is a relationship between the two--if it's never fully exhausted, then there's not going to be breaking changes when adding new variants.

[maciejhirsz]

I'll leave the Error enum as is then, don't really want to add "unknown error" to printing traits either.