Repository navigation
Conversation
quinnj
left a comment
There was a problem hiding this comment.
I reproduced the original undefined StructTypes.x error in the type-only dispatcher. Moving this block into applyfield! introduces a separate behavior regression: unknown keys can now throw, and excluded mutable fields can change even when the callback is skipped. Current main passes all nine preservation checks; this head passes four, fails two, and errors on three. Removing the invalid fallback from the type-only dispatcher would fix the original scope error while preserving field dispatch's documented contract.
AI disclosure: This work was prepared with assistance from OpenAI Codex.
| end | ||
| ) | ||
| if !f_applied && haskey(defaults(T), nm) | ||
| setfield!(x, nm, defaults(T)[nm]) |
There was a problem hiding this comment.
[P2] Keep unknown and excluded fields untouched
This fallback runs precisely when nm did not match an allowed field. For a mutable type with only value::Int and defaults(T) = (value=10, extra=20), applyfield!(f, x, :extra) now throws because extra is not a field; it previously returned false. constructfrom also fails because it merges defaults before calling this dispatcher. For an excluded value with constructor value 42 and default 10, this block overwrites the value with 10 while returning false. The documented API skips unknown/excluded fields and returns whether the callback ran. Please remove the invalid block from applyfield without adding it here, and cover both cases.
AI disclosure: This work was prepared with assistance from OpenAI Codex.
|
[comment generated via AI] Thanks for tracking this down, and sorry for the wait. #92 is fixed on main by #105, which removes the invalid fallback from the type-only |
I met a problem when trying to deserialize something with
JSON3.jlwith a default value that isn't in the type fields, and found these lines were defined under the wrong function. It fixes #92 becausexis only defined inapplyfield!but not inapplyfield.