-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confusing merge behaviour in std.record.{update,remove}
#1866
Comments
Thanks for reporting. This is definitely a bug. I think the original design guideline was that only merge could impact recursive fields, and as soon as you use a record as a "normal" dictionary ( Following this guideline, I believe the right result should be the following:
I see two ways to achieve that:
I think 1. is a simpler mental model: you don't have to think about what fields were removed or not, as soon as you use one |
Describe the bug
The
std.record.update
andstd.record.remove
functions don't recalculate changes in fields that depend on the modified field, but those recalculations do take effect after a merge, even a trivial one (& {}
).To Reproduce
Expected behavior
This might be a language design question, but the least surprising to me would be:
(And in general attempt to enforce that
x & {}
is always equivalent tox
ifx
is a record, unless there is a subtle reason that shouldn't be the case.)Environment
Additional context
I ran into this while testing out some more complicated merging/overriding scenarios, and this behaviour was a lot more surprising in context before I tracked down what made "recalculation" of a field happen or not happen.
The text was updated successfully, but these errors were encountered: