#[derive(Decodable)]Expand description
Derives Decodable<D> for T where D: SpanDecoder
§Deriving decoding traits
Some shared docs about decoding traits, since this is likely the first trait you find
The difference between these derives can be subtle!
At a high level, there’s the T: Decodable<D> trait that says some type T
can be decoded using a decoder D. There are various decoders!
The different derives place different trait bounds on this type D.
Even though this derive, based on its name, seems like the most vanilla one,
it actually places a pretty strict bound on D: SpanDecoder.
It means that types that derive this can contain spans, among other things,
and still be decoded. The reason this is hard is that at least in metadata,
spans can only be decoded later, once some information from the header
is already decoded to properly deal with spans.
The hierarchy is roughly:
- derive
Decodable_NoContextis the most relaxed bounds that could be placed onD, and is only really suited for structs and enums containing primitive types. - derive
BlobDecodablemay be a better default, than derivingDecodable: it places fewer requirements onD, while still allowing some complex types to be decoded. - derive
LazyDecodable: Only for types containingLazy{Array,Table,Value}. - derive
Decodablefor structures containing spans. RequiresD: SpanDecoder - derive
TyDecodablefor types that require access to theTyCtxtwhile decoding. For example: arena allocated types.