Perhaps at some point in the future we should consider adding a new directive that would instruct the DSDL processing tool that the definition where the directive is located should adhere to a conventional layout. It could be called @zerocost.
A data schema is of a “conventional layout” if:
- It is not a tagged union.
- Each field is of a standard bit length (8, 16, 32, 64).
- The offset of each field is an integer multiple of the size of the field. In other words, in a data schema that is of a conventional layout the natural alignment requirement of each field is satisfied. Example:
@zerocost
uint64 foo
int8 bar
uint8 baz
float16 boo
float32[9] zoo
The idea of conventional layout schemas is that on a typical little-endian machine their native memory layout will match their serialized representation, enabling zero-cost serialization via naive memcpy(). One can define zero-cost types without any explicit support from DSDL, of course; the only reason for having the new directive is to let the DSDL front-end catch data types that claim to be zero-cost while not actually being so. Example:
@zerocost
uint64 foo
int8 bar
float16 boo # Oops! Bad alignment - not zero-cost.
uint8 baz
float32[9] zoo
The described feature does not seem to be compatible with variable-length entities, though, meaning that anything that contains a variable-length array is not zero-cost.