Skip to main content

## 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.