Module fields 

Where a record literal’s fields go, decided once instead of once per record.

A record’s fields are held in one order — by name — because that order is the Map’s iteration, the state digest and the patch stream a replay has to reproduce bit for bit (54). A record literal is written in some other order, usually the declaration’s, so building one meant sorting three to eight names on every construction.

The names are in the source, so the answer is the same every time the literal runs. This pass computes it once and writes it on the node: crate::core::Core::order holds, for each position of the finished record, which written field belongs there — four bits each, so a literal of up to MAX_ORDERED fields carries its whole layout in a u32 that fits in padding Core already had.

Evaluation order is not what changes. A field expression can raise, so the values are still computed in the order they are written; what the permutation removes is the comparing and moving afterwards.

Like crate::frames, being unable to answer is safe: UNORDERED means “sort at run time”, and it is what a literal with a repeated field name, one with more fields than fit, and every program built by something that never runs this pass all carry.

Constants

MAX_ORDERED

How many fields fit in the packed layout: eight, at four bits each.

UNORDERED

No layout on this node: whoever builds the record sorts it, as it did before this pass existed.

Functions

order

The same for one expression, and everything under it.

order_here

The layout of this node alone, for a record synthesised after the pass has run — the splitter’s fused state is the one that is.

order_program

Give every record literal in the program its layout.

place

Put items — a record literal’s fields, in the order they are written — into the order the record holds them in.