Remove codec::Encode and codec::Decode derives from generated APIs by default
#2008
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jsdw
changed the title
codec::Encode and codec::Decode from generated APIs by defaultcodec::Encode and codec::Decode derives from generated APIs by default
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Most APIs in Subxt haven't used
codec::Encodeorcodec::Decodein a while; these traits encode and decode bytes from/to a chain based on the precise shape of our generated types and don't take into account any changes in the chain metadata.One of the issues we recently hit was #2006, whereby
EncodeandDecodederives in our generated APIs were not playing nicely with compact encoded generics.A solution is to migrate our generated APIs away from using
codec::Encodeorcodec::Decodeand relying only onEncodeAsTypeandDecodeAstype, which take the chain metadata into account and handle things like encoding and decoding compact encoded values transparently. This PR takes this path.Users can still derive
EncodeandDecodethemselves on types that they want these traits on, or on everything, but all of the main Subxt interfaces no longer have any reliance on them, and so they do not need to be derviced by default.