You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
toon: the list form does not round-trip a nested object value #188
A nested object as a list item's value does not survive a round trip, in two shapes:
input
encode
decode
reference
[{'d': {}}]
[1]:\n -\n d:
[{}] — d dropped
[1]:\n - d: — round-trips
[{'d': {'x': 1}}, {'d': {'y': 2}}]
[2]:\n -\n d:\n x: 1
ToonDecodeError: Expected 2 items, got 1
round-trips
Both are present on master before the TOON 4.1 tracking work (#186), which leaves them untouched — found while reviewing it, not introduced there.
The first is the worse of the two: it silently returns a different object rather than raising. The second is a ToonDecodeError on the encoder's own output.
The encoding also differs from the reference, which writes the item header and its key on one line (- d:) rather than a bare - followed by an indented key.
That PR's oracle is assert_encode_same, which compares encodings. Neither case is in its matrix, so the suite is green on both.
Fix
The list form's item header and the decoder's nested-block handling are the two places to look; the shapes above reproduce on master and on fix/toon-spec-4.1.
Scope correction, from measuring it rather than from the two shapes above.
I fuzzed 1200 generated documents against the reference and split by which path the encoder took:
tabular header path: 226 of 226 encodings agree with the reference, no divergence
list form: 442 of 1200 diverge
Every one of those 974 list-form documents is byte-identical to what master encodes, so none of it is new — the two shapes in this issue are examples of a family, not the whole of it. The family is "an array of objects that does not qualify for a tabular header, containing a nested object or an array value": the list form writes a bare - and an indented key rather than - key:, and its decoder does not rebuild the nested block.
So this is not two edge cases to patch; the list form's item header and its nested-block decoding are both wrong against the reference. Worth knowing before someone estimates it as a small fix, and worth widening the gate beyond the two rows above.
Activity
clementine-oaklight commentedon Oct 13, 2026
Scope correction, from measuring it rather than from the two shapes above.
I fuzzed 1200 generated documents against the reference and split by which path the encoder took:
Every one of those 974 list-form documents is byte-identical to what master encodes, so none of it is new — the two shapes in this issue are examples of a family, not the whole of it. The family is "an array of objects that does not qualify for a tabular header, containing a nested object or an array value": the list form writes a bare
-and an indented key rather than- key:, and its decoder does not rebuild the nested block.So this is not two edge cases to patch; the list form's item header and its nested-block decoding are both wrong against the reference. Worth knowing before someone estimates it as a small fix, and worth widening the gate beyond the two rows above.
docs(toon): spec 4.4, 564/564 conformance, 0.6.0 options
docs(toon):TOON 4.4、564/564 一致性、0.6.0 选项
feat(toon): implement TOON 4.4 and fix list-form nested objects