Is your feature request related to a problem? Please describe.
We decided that empty optional fields should be ignored by all record operations (at least the one from the stdlib), for good reasons.
However, it turns out you sometime wants to list all the field of a record contracts, including the optional ones. In fact, we do have internally variants of has_field, remove, etc. that take empty optional fields into account, but those aren't exposed as primop in the syntax, and thus not as stdlib functions either.
Describe the solution you'd like
Have variants of relevant record functions that consider all fields of a record, without ignoring empty optional fields. We should probably use a common suffix - _all might be a good candidate, although it might be slightly misleading for remove.
Affected functions:
std.record.fields
std.record.has_field
std.record.remove (whether remove fails on an empty optional field or not)
update isn't concerned, because it already unconditionally uses %remove_all% under the hood (there's no good reason to use remove).
yannham
commented
3 months ago
Is your feature request related to a problem? Please describe. We decided that empty optional fields should be ignored by all record operations (at least the one from the stdlib), for good reasons.
However, it turns out you sometime wants to list all the field of a record contracts, including the optional ones. In fact, we do have internally variants of
has_field,remove, etc. that take empty optional fields into account, but those aren't exposed as primop in the syntax, and thus not as stdlib functions either.Describe the solution you'd like
Have variants of relevant record functions that consider all fields of a record, without ignoring empty optional fields. We should probably use a common suffix -
_allmight be a good candidate, although it might be slightly misleading forremove.Affected functions:
std.record.fieldsstd.record.has_fieldstd.record.remove(whetherremovefails on an empty optional field or not)updateisn't concerned, because it already unconditionally uses%remove_all%under the hood (there's no good reason to useremove).