pub fn place<T>(items: &mut [T], order: u32)Expand description
Put items — a record literal’s fields, in the order they are written — into the order the
record holds them in.
One allocation, and it is the caller’s. That is the whole design constraint: the vector of
evaluated fields already exists, so this permutes it where it lies rather than selecting out of
it into a second one. Building the answer into a fresh vector was tried and measured, and it
cost more than the sort it replaced — an allocation is dearer than an insertion sort over four
names (78 §78.3).
The permutation is followed in its cycles, which needs somewhere to record what has already
been placed; here that is the packed layout itself, copied into a local and rewritten as it
goes. So the bookkeeping is a u32 in a register and the whole of this touches no memory but
the elements it moves.
The caller has established that the node carries a layout (UNORDERED does not) and that the
record is no wider than MAX_ORDERED.