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 not non_exhaustive, meaning that any custom serialization implementation would break anyways as soon fields are added to one of them, just in case of bdk_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.
Describe the enhancement
The
non_exhaustiveattribute 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
ChangeSetI'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
ChangeSettypes 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::ChangeSetthe API is different.Use case
Implementing custom serialization logic. Currently, you have to call
ChangeSet::default()and override any deserialized fields manually.