Should bdk_wallet::ChangeSet
really be non_exhaustive
?
#1591
Labels
Milestone
bdk_wallet::ChangeSet
really be non_exhaustive
?
#1591
Describe the enhancement
The
non_exhaustive
attribute disallows the construction of a type via struct expressions to make sure existing code doesn't break at compile time when new variants are added.However, in case of
ChangeSet
I'd want to raise the question if we really want this behavior, or if you'd explicitly want existing code to break at compile time so that, if you implement custom serialization logic, you're forced to look at how to deal with the newly added field during version upgrades.Otherwise, newly added field might get unnoticed by custom implementations as backwards compatibility should ensure prior code continues to be working, although then possibly not with the full feature set of the upgraded version.
FWIW, it's currently also inconsistent across
ChangeSet
types as all others are notnon_exhaustive
, meaning that any custom serialization implementation would break anyways as soon fields are added to one of them, just in case ofbdk_wallet::ChangeSet
the API is different.Use case
Implementing custom serialization logic. Currently, you have to call
ChangeSet::default()
and override any deserialized fields manually.The text was updated successfully, but these errors were encountered: