Open thomaseizinger opened 1 year ago
but that can be solved by adding
is_
getters.
How are these different to a non-opaque struct with a non_exhaustive
? Removing them would still be a breaking change, right?
Asked differently, why not just a non_exhaustive
like on the std
ErrorKind
?
but that can be solved by adding
is_
getters.How are these different to a non-opaque struct with a
non_exhaustive
? Removing them would still be a breaking change, right?
They can be more easily deprecated with fallback functionality. With an enum variant, you can only either return one or the other, meaning if you deprecate it, the user can't meaningfully migrate to something new because you can't emit "both".
With functions, you can deprecate one and have it call the new one internally.
As an effort towards #71, I propose to make
Error
an opaque struct. This allows us to rename variants, as well as add or remove some of them or change their internal representation without any breaking changes.We lose the ability to match the specific one but that can be solved by adding
is_
getters. Should we add them right away for all variants?