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.
0.11.0 - 2023-02-09
Up until now, this crate depended heavily on
scale_info
to provide the type information that we used to drive our decoding of types. This release removes the explicit dependency onscale-info
, and instead depends onscale-type-resolver
, which offers a genericTypeResolver
trait whose implementations are able to provide the information needed to decode types (see this PR for more details). So now, the traits and types inscale-decode
have been made generic over whichTypeResolver
is used to help decode things.scale-info::PortableRegistry
is one such implementation ofTypeResolver
, and so can continue to be used in a similar way to before.The main breaking changes are:
Visitor trait
The
scale_decode::Visitor
trait now has an additional associated type,TypeResolver
.The simplest change to recover the previous behaviour is to just continue to use
scale_info::PortableRegistry
for this task, as was the case implicitly before:A better change is to make your
Visitor
impls generic over what is used to resolve types unless you need a specific resolver:IntoVisitor trait
scale_decode::IntoVisitor
is implemented on all types that have an associatedVisitor
that we can use to decode it. It used to look like this:Now it looks like this:
What this means is that if you want to implement
IntoVisitor
for some type, then yourVisitor
must be able to accept any validTypeResolver
. This allowsDecodeAsType
to also be generic over whichTypeResolver
is provided.DecodeAsType
This trait previously was specific to
scale_info::PortableRegistry
and looked something like this:Now, it is generic over which type resolver to use (and as a side effect, requires a reference to the
type_id
now, because it may not beCopy
any more):This is automatically implemented for all types which implement
IntoVisitor
, as before.Composite and Variant paths
Mostly, the changes just exist to make things generic over the
TypeResolver
. One consequence of this is that Composite and Variant types no longer know their path, because currentlyTypeResolver
doesn't provide that information (since it's not necessary to the actual encoding/decoding of types). If there is demand for this, we can consider allowingTypeResolver
impls to optionally provide these extra details.