Memory Layout and Representation

Purpose

The layout model connects Sec's semantic types to concrete storage representation. It is used by allocation, raw memory access, FFI, hardware access, ABI lowering, compile-time layout queries and backend code generation.

Layout is always resolved under the active target/profile rather than copied from the machine that happens to run the compiler.

What Layout Does Not Define

Layout does not decide:

• who owns a value;
• where the storage came from;
• how long the storage remains valid;
• whether the storage may relocate;
• how storage is allocated;
• how function parameters are passed in registers/stack;
• whether a value may cross an FFI boundary;
• how values are serialized;
• whether a reference is valid.

Ownership, storage, allocation, lifetime, ABI and FFI rules consume layout facts but remain separate semantic systems.

Core Principles

• Layout is resolved for one concrete CompilationPlan.
• Sec distinguishes semantic layout, native layout and explicit layout.
• Materialized struct fields retain declaration order.
• Native padding is not semantic data.
• Physical layout similarity does not imply type compatibility.
• Storage layout and callable ABI are separate.
• A by-value stored value requires complete sized layout.
• Size and alignment do not prove that every bit pattern is valid.
• Initialization is separate from layout.
• Direct recursive by-value layout is invalid.
• Generic layout is resolved per concrete instantiation.
• Backends consume Sec-resolved layout and do not redefine it independently.

Layout Depends on the CompilationPlan

Layout-relevant plan facts include:

• architecture;
• pointer width;
• target data layout;
• target endianness;
• selected ABI;
• target profile;
• supported scalar and aggregate alignments;
• supported unaligned accesses;
• explicit layout contracts;
• concrete generic arguments;
• selected safe-reference representation;
• selected descriptor representation.

The same semantic Sec type may therefore have a different native size, alignment or descriptor representation on different targets.

Multi-output builds resolve layout independently for every concrete output plan.

Three Layout Levels

Semantic Layout

Semantic layout includes facts such as:

• a struct contains its stored fields;
• stored struct fields retain declaration order;
• T[N] contains exactly N inline elements;
• fixed-array elements occur in increasing index order;
• an enum has its selected underlying representation;
• a union has one active variant and stable declaration-order variant identities;
• a register has its declared semantic bit width;
• named types retain nominal identity;
• properties and methods do not add stored instance fields.

Semantic layout does not necessarily fix byte size, alignment, padding or field offsets.

Native Layout

Native layout is the target-resolved physical representation chosen by Sec under one concrete compilation plan.

It may include:

• size;
• alignment;
• field offsets;
• padding ranges;
• element stride;
• union tag type and offset;
• union payload placement;
• descriptor representation;
• reference representation;
• validity metadata representation.

Native layout may differ across targets, ABIs, profiles and compiler versions. It is not automatically a portable serialization or persistence format.

Explicit Layout

Explicit layout constrains physical representation beyond ordinary native layout.

A representation contract may eventually constrain properties such as:

• field order;
• field offsets;
• field alignment;
• aggregate alignment;
• packing;
• total size;
• endianness;
• tag representation;
• payload placement.

Only properties explicitly fixed by the contract become guarantees. Unconstrained properties continue to use native layout rules.

An explicit layout contract does not automatically:

• change nominal type identity;
• make a type FFI-compatible;
• make a type serializable;
• make raw byte reinterpretation safe;
• override ownership, lifetime, allocation or destruction rules.

Layout Stability

Useful semantic stability classes are:

CompilationLocal
TargetStable
ContractStable

Ordinary native layout is compilation-local unless a stronger target/profile or explicit contract guarantees selected properties.

Target-stable representation is stable only within the named target/profile guarantee.

Contract-stable representation guarantees only the properties actually named by the explicit representation contract.

Equal native layout observed today is never by itself a cross-version or cross-target guarantee.

Complete and Incomplete Layout

A layout is complete when every physical property required by the current use has been resolved.

Layout may remain incomplete while target information or concrete generic arguments are not yet available.

Complete layout is required before operations such as:

• by-value storage;
• field-offset queries;
• ABI materialization;
• raw memory access;
• layout-sensitive lowering.

The compiler never assigns guessed size or alignment to an incomplete type.

Sized Values

A by-value materialized type must have finite target-representable size.

Zero-sized types are still sized types.

Runtime-sized backing storage does not make a descriptor value itself unsized. In particular, a bare owning dynamic array T[] is a sized descriptor whose element backing storage is separate.

Likewise, ref T[] and ref mut T[] are sized non-owning descriptor/reference values under the active reference profile.

Size

TypeName.SizeOf returns the byte size of the complete materialized representation of a type for the active plan.

let pointSize: uint := Point.SizeOf
let valueSize: uint := value.SizeOf

Size:

• includes required padding inside the representation;
• includes required tail padding;
• excludes separately owned backing storage unless embedded by the type representation;
• uses checked arithmetic;
• is evaluated using target layout, not compiler-host layout.

Descriptor size is the size of the descriptor itself, not the total memory reachable through that descriptor.

void has no ordinary materialized value layout, so void.SizeOf is invalid.

Alignment

Alignment is the placement requirement for the beginning of a materialized value.

Native alignment is target-dependent unless a semantic or explicit contract fixes it.

Alignment is not automatically equal to size. A wide scalar may legally have alignment smaller than its byte size.

A safe reference cannot be formed to storage that fails the alignment required by its referent representation.

unsafe does not create hardware support for unaligned accesses. Unaligned operations require target-supported semantics.

Stride

Stride is the byte distance between corresponding starts of adjacent elements in a materialized sequence.

Stride must satisfy the element's size, alignment and target layout rules. It may exceed semantic element data size because of padding.

Raw-pointer Offset(elements) uses the canonical element size/stride semantics defined by raw-pointer and layout rules.

Padding

Padding is physical representation space that does not belong to a semantic field, element or active payload.

Padding:

• has no semantic Sec type;
• has no field identity;
• has no object lifetime;
• is not initialized merely because surrounding fields are initialized;
• need not contain deterministic bytes.

Ordinary equality, hashing and serialization must not accidentally treat unspecified padding as semantic data.

A low-level representation copy may copy padding when that is representation-safe, but safe code must not thereby gain observable access to uninitialized padding.

FFI or byte-export paths must prevent padding leaks where their security/ABI contract requires deterministic or initialized representation.

Stored Field Placement

Native Sec struct layout preserves stored fields in declaration order.

The compiler may insert padding between fields and after the final field, but does not reorder ordinary stored fields merely to reduce size.

The following do not add stored instance bytes:

• properties;
• methods;
• nested type declarations;
• constants;
• interface conformance;
• documentation;
• visibility metadata;
• ordinary impl declarations.

Fixed Arrays

T[N] contains exactly N inline element slots.

The length is compile-time known. Zero-length fixed arrays are valid where the element/layout rules permit them.

A fixed array contains no hidden pointer, length, capacity or allocator field.

Total size is computed using canonical element stride and count with checked arithmetic.

Embedded fixed arrays move and relocate with their enclosing storage.

Struct Layout

For a normal native struct, layout conceptually follows declaration order:

currentOffset = 0

for each stored field:
    align currentOffset for the field
    place the field
    advance by field size

align total size for the aggregate

All layout arithmetic is checked. Overflow is a compile-time layout error.

type Example struct {
    first: byte
    second: uint32
    third: byte
}

Physical order remains:

first
padding when required
second
third
tail padding when required

The compiler does not place second first merely to reduce padding.

Empty Structs and Zero-Sized Fields

An empty struct has:

size:      0
alignment: 1

It remains a real semantic type and value.

Zero-sized stored fields retain semantic field identity even though they consume no payload bytes and may share a numeric address with other zero-sized values or surrounding storage.

Semantic identity must never be inferred solely from a numeric address.

Enum Layout

A fieldless enum with a selected scalar underlying representation occupies that representation unless another canonical enum/layout rule requires more.

Explicit enum values must fit the selected underlying type.

Bit-backed enums use their canonical bit width.

String-underlying enums remain semantic enum types and follow their canonical string-backed representation rather than being silently lowered as C integers.

Backend legacy paths must not force all default enums to i32 when the Sec type/target model requires another representation.

Tagged Union Layout

A tagged Sec union needs:

• a discriminator identifying the active variant;
• payload storage large/aligned enough for every possible payload.

Variant semantic identity and order come from the declaration. Native tag width and placement may be target/layout dependent.

Inactive payload bytes and padding are not semantic data. The compiler must not read inactive payload storage as another variant.

Niche/tag-elision optimization is legal only after Sec proves that every semantic, ownership, reference and representation-validity invariant is preserved.

Result and Option

Result[T,E] and Option[T] are semantic variant values.

Their physical representation may use a canonical niche or tag optimization, but their semantic alternatives remain explicit.

Backend code must not invent a niche optimization independently of Sec-resolved layout.

Representation optimization must preserve matching, ownership, destruction, references and FFI semantics.

Register Layout

Register declarations have exact semantic bit widths defined by the register rules.

Register bit fields describe semantic hardware bit positions, not ordinary struct byte offsets.

Before physical access, the target must validate:

• storage unit;
• alignment;
• access width;
• endianness;
• hardware-access constraints.

Signal polarity such as active-high/active-low is not layout semantics.

Scalar Layout

Fixed-width integer byte sizes are exact:

Their natural alignment follows the active target data layout and need not equal size.

byte has the same native physical layout as uint8 while remaining its own canonical Sec scalar type.

int and uint Are Pointer-Sized

32-bit plan:
    int  = 32-bit signed integer
    uint = 32-bit unsigned integer

64-bit plan:
    int  = 64-bit signed integer
    uint = 64-bit unsigned integer

Their size follows the canonical pointer width of the active compilation plan.

This rule must be used consistently in semantic analysis, layout queries, enum representation, MLIR, LLVM, ABI and FFI validation.

bool

An addressable bool occupies one byte and has alignment one.

Only canonical false and true representations are valid safe materialized bool values.

A backend may use a narrower SSA/register representation internally when the value is not materialized and conversions preserve the canonical stored representation.

rune

rune uses a 32-bit scalar representation.

Only valid Unicode scalar values are valid safe rune representations. Surrogates and values outside the Unicode scalar range are invalid.

Floating-Point Values

float32
    IEEE-754 binary32
    size: 4 bytes

float64
    IEEE-754 binary64
    size: 8 bytes

float
    same numeric width and native layout as float64

Alignment follows the active target data layout.

decimal and decimal128

The canonical native component representations are:

decimal:
    coefficient: int64
    scale:       int32

decimal128:
    coefficient: int128
    scale:       int32

These composite scalar representations use ordinary target-resolved aggregate placement for their components, including any required padding.

RawPtr[T] Layout

RawPtr[T] uses the selected target raw-pointer representation for its address space.

The pointee type does not change ordinary raw-pointer width.

Capability/tagged/non-flat targets may require a richer raw-pointer representation.

Raw-pointer layout never implies:

• ownership;
• valid provenance;
• pointee validity;
• bounds;
• non-nullness;
• lifetime.

Named Types, Contracts and Units

A named type normally uses the same native physical layout as its underlying type unless a future explicit representation contract says otherwise.

type CustomerID uint64
type ProductID uint64
type Percent int range 0..100
type Meter decimal<m>

The following do not add hidden per-value bytes merely by existing:

• nominal identity;
• range contracts;
• unit metadata;
• regex/length contracts;
• methods;
• properties;
• impl blocks;
• interface conformance.

Two named types may have exactly the same physical layout and still be incompatible semantic Sec types.

String Layout

The materialized string descriptor representation is selected by the canonical string/reference/layout model for the active plan.

string.SizeOf describes the descriptor representation, not separately stored character backing.

Static literal storage, borrowed/view storage and owned string storage may use different storage contracts without changing semantic string identity where the string rules allow it.

Layout must not assume that every string owns heap storage.

Collection Descriptors

Owning dynamic collection values are sized descriptors unless their specific collection rule defines an embedded representation.

Descriptor layout contains only state physically stored in the descriptor. Separately owned element backing is not part of the descriptor's SizeOf.

Length, capacity and reference/pointer representation are selected by the canonical collection/layout/profile model.

Safe Reference Layout

Source-level ref T and ref mut T do not require one universal physical representation across all profiles.

A proven reference may lower to one machine address when all required validity facts are statically established.

Other profiles may require metadata for generation, epoch, capability or address space.

Safe-reference layout remains semantically distinct from RawPtr[T] even where both happen to occupy one machine word on a particular target.

Zero-Sized Types

Zero-sized types have size zero while remaining real semantic values.

Arrays of zero-sized elements retain their semantic element count.

Numeric addresses alone cannot be used to infer identity between distinct zero-sized fields or elements.

Pointer/reference arithmetic for zero-sized element types requires dedicated canonical semantics and is not inferred from arbitrary address changes.

Recursive Layout

Layout resolution follows a by-value dependency graph.

This is invalid in principle:

type Node struct {
    Next: Node
}

Direct recursive by-value containment has no finite complete representation.

Recursion through a reference, raw pointer, owning dynamic descriptor or another valid indirection/storage boundary may be valid because the recursive payload is not embedded inline by value.

Generic instantiation can introduce a recursive layout cycle even when the generic declaration alone appears harmless.

Generic Layout

Generic declarations do not have one universal concrete native layout.

type Pair[A, B] struct {
    first: A
    second: B
}

These may all resolve differently:

Pair[int32, byte]
Pair[decimal, string]
Pair[CustomerID, ProductID]

Layout is resolved and cached using concrete semantic type identity together with all relevant compilation-plan facts.

Packing

Packing is an explicit layout contract that reduces or removes ordinary padding and/or alignment placement.

Packing does not change semantic field identity or declaration order.

Packed fields may become physically misaligned. Sec must never form an ordinary aligned safe reference to a misaligned field.

Access may require compiler-generated unaligned operations or explicit target-supported unsafe/platform operations.

Explicit Alignment

An explicit layout contract may raise or otherwise constrain a value's required alignment subject to target capability.

Over-aligned storage also requires an allocator/storage provider capable of satisfying that alignment.

Explicit alignment changes placement requirements but does not by itself change semantic type compatibility.

Explicit Field Offsets

Explicit offsets may constrain where stored fields begin.

A valid contract must respect:

• field size;
• required alignment unless explicit unaligned semantics permit otherwise;
• total representation bounds;
• ordinary struct non-overlap rules.

Overlapping stored fields require an explicitly defined union/overlay representation. Ordinary structs do not gain accidental overlap.

Endianness

Target endianness is part of the active CompilationPlan.

Native integer and scalar representation follows target endianness where representation becomes observable through low-level operations.

Endianness is not ordinary semantic numeric identity. The integer value 1 is still the same numeric value regardless of byte order.

Network/protocol serialization order remains the responsibility of serialization and protocol APIs unless an explicit representation contract deliberately fixes storage byte order.

Representation Validity

Correct size and alignment are not enough to make arbitrary bits a valid value of a Sec type.

Validity may include:

• valid enum discriminants;
• valid active union state;
• canonical bool representation;
• valid rune/character values;
• safe-reference invariants;
• representation-relevant named-type invariants;
• other canonical type constraints.

Raw or uninitialized storage cannot become readable T until the validity obligations for T have been established.

unsafe may create proof obligations, but it cannot make a compiler-proven invalid representation valid.

Initialization and Padding

Initializing an object establishes semantic fields and payload values. It does not necessarily assign deterministic semantic content to padding bytes.

Safe code must not observe uninitialized padding as semantic data.

Zero-initializing raw bytes is a valid way to construct T only when T's representation rules say the all-zero bit pattern is a valid value.

Semantic default initialization is therefore not synonymous with “fill every byte with zero”.

Layout Compatibility

Equal size, alignment and field offsets do not make two Sec types safely interchangeable.

Layout compatibility is a separately verified relation for a specific purpose, such as FFI or an explicit representation conversion.

A compatibility proof may need to include:

• representation validity;
• alignment;
• field/variant meaning;
• endianness;
• ABI requirements;
• target constraints.

Native layout coincidence is never a portable compatibility guarantee.

Layout Queries

The currently established user-facing size queries are:

TypeName.SizeOf
value.SizeOf

Layout semantics also define concepts corresponding to alignment, stride and field offset queries where compiler-known-member rules provide a source surface.

Any query requiring target-resolved layout runs under one concrete compilation plan.

A query fails at compile time when the requested layout is incomplete or unavailable.

Observing a layout through a query does not make that layout stable across other plans or compiler versions.

FFI Layout

Native Sec layout is not automatically C-compatible merely because measured sizes look similar.

Foreign structs, unions and enums require explicit compatibility with the selected ABI and foreign representation contract.

Padding, alignment, packing and endianness requirements must be represented and validated.

Function calling convention and ABI classification remain separate from storage layout, although ABI lowering consumes resolved layout.

Hardware and Register Layout

Fixed-address placement does not change the type's layout. It changes where and how the storage is accessed.

MMIO may require exact access widths that are stricter than ordinary load/store choices.

Register views and mappings therefore combine:

• canonical register/layout facts;
• target storage requirements;
• volatile/MMIO access contracts;
• fixed-address or runtime mapping rules.

Representation Observability

Ordinary safe Sec code should not depend on unspecified native padding or backend-only representation details.

Representation becomes observable through operations such as:

• layout queries;
• FFI;
• raw/unsafe memory access;
• serialization adapters;
• hardware/register access;
• inline assembly;
• other canonical low-level interfaces.

Once representation is observably part of a contract, optimization must preserve that contract.

Semantic IR and Lowering

Layout-sensitive lowering must consume one canonical Sec-resolved layout model rather than allowing MLIR and LLVM to independently redefine source representation.

A resolved layout service needs facts such as:

• semantic type identity;
• compilation-plan identity;
• size;
• alignment;
• completeness;
• field identities and offsets;
• array stride;
• union representation;
• padding where relevant;
• representation validity;
• stability and explicit-contract provenance.

MLIR/LLVM data-layout facilities may assist target calculation. They are not a second normative Sec layout engine.

Lowering must not silently reorder fields, change enum width, reinterpret pointer-sized int/uint, choose incompatible union tags or ignore explicit contracts.

Diagnostics

Layout diagnostics should identify:

• the affected type;
• the target/compilation plan;
• the unresolved or conflicting layout requirement;
• the relevant field, variant or recursive path;
• requested versus target-supported size/alignment/offset when applicable.

Recursive by-value layout

cannot resolve layout of `Node`

by-value layout cycle:
    Node
    -> Node.Next
    -> Node

help: introduce an owning or reference indirection

Unsupported alignment

required alignment cannot be represented by the selected target

type:
    Packet

required alignment:
    64 bytes

target maximum supported alignment:
    16 bytes

Incomplete layout query

layout of `T` is incomplete here

`T.SizeOf` requires a concrete target-resolved layout

help: perform the query after the generic type has been concretely instantiated

Physical similarity is not type compatibility

`CustomerID` and `ProductID` have compatible native size

they remain distinct Sec types

physical representation does not create an implicit conversion

Diagnostics should use programmer-facing terms such as field, offset, alignment, padding and target rather than exposing backend-only LLVM details.

LSP and Tooling

LSP and sec analyse consume the same resolved layout service as compilation.

Tooling may expose:

• size;
• alignment;
• field offsets;
• stride;
• padding;
• layout class/stability;
• target dependence;
• explicit contract provenance;
• descriptor/reference representation;
• incomplete-layout causes.

Tooling must not independently approximate layout from syntax alone.

When no target is resolved, displayed layout information must clearly say that the result is target-dependent or currently unresolved.

Required Future Updates

This page should be rewritten or promoted to revision 1.0 after the following areas are locked and implemented consistently:

• Explicit layout source syntax: final spelling/attachment model for packing, alignment, field offsets, total size, endianness and representation contracts.
• Layout queries: final user-facing forms for alignment, stride and field-offset queries.
• Canonical compiler model: one shared resolved-layout phase and representation for every concrete compilation plan.
• Field offsets and padding: canonical Semantic IR representation of field offsets, padding ranges and aggregate alignment.
• Array stride: complete target-correct stride representation and queries.
• Union representation: canonical tag selection, tag placement, payload placement and resolved-layout object.
• Reference/descriptor layout: one canonical layout record for safe references, slices and owning descriptors under each profile.
• Representation validity: complete validity metadata and zero-initialization checks.
• Padding safety: complete initialization and padding-leak diagnostics.
• Packed/misaligned access: final safe-reference rejection and target-supported unaligned lowering behavior.
• FFI validation: complete explicit foreign-layout/ABI validation.
• Hardware validation: target-specific storage alignment, access unit and MMIO width validation.
• Stability contracts: final source-facing way to request or describe target-stable/contract-stable layout where required.
• Cross-rulebook synchronization: adjacent type, collection, FFI, ABI, register, reference and target-profile documentation must use the same canonical resolved-layout model.

Best Practices

• Do not rely on ordinary native layout as a stable file/network/FFI format.
• Use TypeName.SizeOf or value.SizeOf when actual target-resolved byte size is required.
• Do not assume alignment equals size.
• Keep stored struct field declaration order intentional; Sec preserves it.
• Remember that padding is not semantic field data.
• Do not inspect arbitrary padding bytes in safe code.
• Do not treat all-zero bytes as a valid default for every type.
• Do not infer type compatibility from equal size or field offsets.
• Do not infer reference safety from raw pointer layout.
• Use a canonical explicit representation contract for FFI, shared-memory or hardware layouts once the final syntax is available.
• Do not invent packing/alignment/offset syntax while the language surface remains open.
• Keep target dependence visible in tooling and documentation.

Summary

• Layout describes physical representation of materialized Sec values.
• Layout is resolved for one concrete CompilationPlan.
• The same semantic type may have different native layout on different plans.
• Sec distinguishes semantic, native and explicit layout.
• Semantic layout contains language/type representation facts independent of one target.
• Native layout selects concrete size, alignment, offsets, padding, stride and descriptor/reference representation.
• Explicit layout constrains selected representation properties beyond native layout.
• Final source syntax for explicit layout is not yet locked.
• The manual intentionally does not invent layout, packed, align, offset or endian syntax.
• Ordinary native layout is not automatically stable across targets, profiles, ABIs or compiler versions.
• By-value materialization requires complete sized layout.
• Zero-sized types are still sized semantic values.
• T[] is a sized owning descriptor; runtime-sized element backing is separate storage.
• ref T[] and ref mut T[] are sized non-owning descriptors/references.
• TypeName.SizeOf and value.SizeOf report materialized representation size for the active plan.
• Size includes required padding and excludes separate reachable backing storage.
• Alignment is target-dependent and is not automatically equal to size.
• Misaligned safe references are invalid.
• unsafe does not create target support for unaligned access.
• Stride is the byte distance between adjacent materialized elements and may exceed semantic data size.
• Padding is physical representation space, not semantic Sec data.
• Padding has no field identity or ordinary object lifetime.
• Safe equality/hash/serialization must not accidentally depend on unspecified padding contents.
• Stored struct fields retain declaration order under native Sec layout.
• Native layout may add inter-field and tail padding but does not reorder ordinary fields.
• Properties, methods, nested declarations, impls and interface conformance do not add stored instance fields.
• Fixed arrays contain exactly N inline element slots and no hidden pointer/length/capacity/allocator fields.
• Fixed-array layout uses checked element-stride arithmetic.
• Empty structs have size zero and alignment one.
• Zero-sized fields retain semantic field identity despite consuming no payload bytes.
• Enum layout follows its canonical underlying representation and value constraints.
• String-underlying enums are not silently represented as C integers.
• Tagged unions contain discriminator semantics plus sufficient payload representation.
• Inactive union payload bytes are not semantic data.
• Niche/tag-elision optimization requires Sec-level proof.
• Result and Option may use canonical physical optimizations without changing semantic alternatives.
• Register bit positions are hardware bit layout, not ordinary struct byte offsets.
• Fixed-width integer byte sizes are exact while alignments follow the active target.
• int and uint use the active target's canonical pointer-sized integer width.
• Addressable bool occupies one byte; internal SSA may use a narrower representation.
• rune uses 32-bit storage but not every 32-bit pattern is a valid rune.
• float32 and float64 use IEEE binary32/binary64 representation.
• decimal and decimal128 use canonical coefficient/scale component representations.
• RawPtr[T] uses the target raw-pointer/address-space representation.
• Raw pointer layout does not imply ownership, provenance, bounds, non-nullness or lifetime.
• Named types usually reuse underlying physical layout without losing nominal type identity.
• Contracts, units, methods and properties do not automatically add hidden per-value bytes.
• String SizeOf describes its descriptor, not separate character backing.
• Dynamic collection SizeOf describes descriptor state, not separately owned element backing.
• Safe reference representation may differ by profile and remains distinct from RawPtr semantics.
• Direct recursive by-value layout is invalid.
• Recursive types may be valid through reference/raw-pointer/dynamic-storage indirection.
• Generic layout is resolved per concrete instantiation and compilation plan.
• Packing, explicit alignment and explicit offsets have defined semantic requirements but unfinished source syntax.
• Target endianness is a compilation-plan fact, not ordinary numeric value identity.
• Correct size/alignment does not imply that every bit pattern is a valid value.
• Raw/uninitialized storage cannot be read as T until T's representation validity is established.
• Semantic default initialization is not equivalent to zero-filling all bytes.
• Equal physical layout does not imply Sec type compatibility.
• Native layout is not automatically C-compatible.
• Hardware/fixed-address placement consumes layout but remains a separate storage/access contract.
• Representation becomes observable through low-level contracts such as FFI, raw access, hardware, inline assembly and layout queries.
• Once representation is observable, optimization must preserve the corresponding contract.
• Semantic IR and lowering must consume canonical Sec-resolved layout rather than letting backends redefine it.
• The canonical shared ResolvedLayout implementation is not yet complete.
• Layout tooling must use compiler-resolved facts rather than approximate syntax-only calculations.
• This chapter remains partial until explicit-layout syntax, layout queries and canonical compiler representation are completed.