pub(crate) fn unrecognised(
pairs: &[(Value, Value)],
writes_key: impl Fn(&str) -> bool,
) -> Vec<(Value, Value)>Expand description
Every entry of pairs the decoded map does not write back out of a field
of its own: a key this crate has never heard of, a key it knows whose value
it could not use — and a second entry for a key whose first entry a field
did take.
That last case is why this walks entries rather than filtering on key
names. Every field is read through find, which returns the first entry
for its key, so a header carrying "transport": "wt" and then
"transport": 42 hands "wt" to the field and leaves the 42
unaccounted for. Filtering the store by key name dropped that entry along
with the one the field was holding, and a value the file carried reached
neither the field nor the store: reading the file deleted it outright.
RFC 8949 makes such a map invalid and SPEC.md leaves readers free to
disagree over which entry of a duplicate pair wins, but neither licenses
losing the other one on the way in.
The kept entry is not written back — store_entries drops it, because
the field writes that key and a map may not carry it twice — so a rewrite
of a duplicate-keyed map emits one entry of the pair, which is the most a
conformant writer can emit, and is a fixed point from there.
Events use this too, with their own writes_key. Which entry a field
actually took is the caller’s business, not this walk’s: a lookup that
returns the first entry for a key whatever it holds leaves the first, and
one that skips an entry whose value it cannot use may leave a later one.
This drops the first entry for a key the map writes either way, so on a
mixed-type duplicate the two disagree about which entry survives. Both
were lost before this walk existed, and SPEC.md leaves readers free to
disagree over which of a duplicate pair wins, so nothing may depend on it.