Mark error variants as nonexhaustive
Nemo157 opened this issue · 2 comments
#12 adds in some new bs58::decode::DecodeError variants. Technically this is a breaking change, but I have looked at every dependent crate on crates.io and all usage I could find on github and nobody is currently depending on the variants. So I'm ok with releasing a patch-version bump to extend the error variants and mark them as nonexhaustive to avoid any future breakage if there need to be new variants.
I could create a new error enum (maybe DecodeCheckError, make it feature dependent). Would not be much work. Would that be better?
I don't think it's worth it, I'm completely fine with doing this technically breaking change. The fact that none of the users are introspecting the error details at all yet implies that I would probably have been fine to just return a string for errors anyway. Having the enum change based on features might be something I'll try out, once it's non-exhaustive then having a feature add extra variants should be workable; but I'll have to see what it feels like to use to see if even that's worth it.