Decodable

Derive Macro Decodable 

Source
#[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_NoContext is the most relaxed bounds that could be placed on D, and is only really suited for structs and enums containing primitive types.
  • derive BlobDecodable may be a better default, than deriving Decodable: it places fewer requirements on D, while still allowing some complex types to be decoded.
  • derive LazyDecodable: Only for types containing Lazy{Array,Table,Value}.
  • derive Decodable for structures containing spans. Requires D: SpanDecoder
  • derive TyDecodable for types that require access to the TyCtxt while decoding. For example: arena allocated types.