scale-info ยท
A library to describe Rust types, geared towards providing info about the structure of SCALE encodable types.
The definitions provide third party tools (e.g. a UI client) with information about how they are able to decode types agnostic of language.
At its core is the TypeInfo
trait:
Types implementing this trait build up and return a Type
struct:
Types are defined as one of the following variants:
Built-in Type Definitions
The following "built-in" types have predefined TypeInfo
definitions:
-
Primitives:
bool
,char
,str
,u8
,u16
,u32
,u64
,u128
,i8
,i16
,i32
,i64
,i128
. -
Sequence: Variable size sequence of elements of
T
, whereT
implementsTypeInfo
. e.g.[T]
,&[T]
,&mut [T]
,Vec<T>
-
Array: Fixed size
[T: $n]
for anyT
which implementsTypeInfo
, where$n
is one of the predefined sizes. -
Tuple: Tuples consisting of up to 10 fields with types implementing
TypeInfo
.
User-defined Types
There are two kinds of user-defined types: Composite
and Variant
.
Both make use of the Path
and Field
types in their definition:
Fields
A fundamental building block to represent user defined types is the Field
struct which defines the Type
of a
field together with its optional name. Builders for the user defined types enforce the invariant that either all
fields have a name (e.g. structs) or all fields are unnamed (e.g. tuples).
Path
The path of a type is a unique sequence of identifiers. Rust types typically construct a path from
the namespace and the identifier e.g. foo::bar::Baz
is converted to the path ["foo", "bar", "Baz"]
.
Composite
Composite data types are composed of a set of Fields
.
Structs are represented by a set of named fields, enforced during construction:
Tuples are represented by a set of unnamed fields, enforced during construction:
;
Variant
Variant types aka enums or tagged unions are composed of a set of variants. Variants can have unnamed fields, named fields or no fields at all:
If no variants contain fields then the discriminant can be set explicitly, enforced by the builder during construction:
The Registry
Information about types is provided within the so-called type registry (Registry
).
Type definitions are registered there and are associated with unique IDs that the outside
can refer to, providing a lightweight way to decrease overhead instead of using type
identifiers.
All concrete TypeInfo
structures have two forms:
- One meta form (
MetaType
) that acts as a bridge to other forms - A portable form suitable for serialization.
The IntoPortable
trait must also be implemented in order prepare a type
definition for serialization using an instance of the type registry.
After transformation all type definitions are stored in the type registry. Note that the type registry should be serialized as part of the metadata structure where the registered types are utilized to allow consumers to resolve the types.
Encoding
The type registry can be encoded as:
- JSON (with the "serde" feature enabled).
- SCALE itself (using
parity-scale-codec
).
Features
The following optional cargo
features are available:
- serde includes support for json serialization/deserialization of the type registry. See example here.
- derive reexports the
scale-info-derive
crate.
Known issues
When deriving TypeInfo
for a type with generic compact fields e.g.
You may experience the following error when using this generic type without the correct bounds:
See https://github.com/paritytech/scale-info/issues/65 for more information.
Resources
- See usage for describing types for
ink!
smart contracts metadata. - Original design draft (outdated)