Module default 

The value a member takes when the stream does not carry it.

XTypes 1.3 §7.4.1.2.3: “if the receiver’s member is not optional, it logically takes its default value”. §7.2.4.4.8, Table 19, says the same thing about assignability in general — “Each non-optional member in a T1 object that is not present in the T2 object takes its default value” — so this is the one rule behind both halves of type evolution: a @mutable member the writer omitted and the tail of an @appendable type the writer did not have.

Where the value comes from

Two places, in this order, per §7.2.2.4.4.4.9:

1. The member’s explicit default, if its declaration carries one. “An explicit definition associates a default value with the member at the time where the aggregated type is defined.” That is @default in IDL. member is the entry point that consults it.
2. The type’s implicit default, otherwise: “The implicit default value for a member is defined to match the default value of the member type. See Table 9.” That is of_type.

Substituting Table 9’s zero for a member the designer gave an explicit @default would be a silently wrong value, which is the failure class this project ranks above every other.

Table 9, exactly

Type kind	Default
BYTE	0x00
BOOLEAN	False
INT_8…UINT_64, FLOAT_32, FLOAT_64, FLOAT_128	0
CHAR_8, CHAR_16	'\0'
STRING_TYPE	""
ARRAY_TYPE	the same dimensions, each element at its default
ALIAS_TYPE	the default of the alias’s base type
SEQUENCE_TYPE	a zero-length sequence
MAP_TYPE	an empty map
ENUM_TYPE	the first literal
UNION_TYPE	the discriminator at its default; if that selects a
branch, the selected member at its default too
STRUCTURE_TYPE	no optional members, the others at their
defaults

The three kinds Table 9 does not list

BITMASK_TYPE, BITSET_TYPE and fixed<P,S> have no row. The standing rule where the specification is silent is the broadest and safest reading, written down:

• A bitmask is held in a UInt8/16/32/64 (Table 33) and §7.4.1.1.3.2 puts the bits at or above the bound outside the bitmask. The default of the holder is 0 by Table 9’s integer row, and 0 sets no bit, so the default is the empty set. Table 18 pairs bitmask and enumeration for assignability, which is the same grouping; no reading of either clause produces a bitmask with a bit already set.
• A bitset is likewise packed into an anchor of 1, 2, 4 or 8 bytes, whose Table 9 default is 0; every bitfield reads back 0 out of it. An anonymous bitfield is padding and carries no value, which is what the encoder and the decoder already agree on.
• fixed<P,S> is not in the XTypes type system at all — P4 of docs/wire-feature-inventory.md — so Table 9 could not have a row for it. IDL 4.2 §7.4.1.4.4.3.4 gives it a decimal value, and the only value every other row of Table 9 agrees on is zero. Written with the type’s own scale, because that is the one spelling of zero canonical::decimal accepts for the type.

Each is the same answer the type’s serialised zero would decode to, which is the property that makes the reading safe: a peer that wrote the member at its default and a peer that omitted it hand the receiver the same value.

Functions

member

The default value of one member: its @default, or its type’s.

of_type

Table 9’s default for a type, with no member annotation in play.