-
Notifications
You must be signed in to change notification settings - Fork 15
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
Add support for .default
#42
Comments
This is also used by the governance cip: https://github.com/cardano-foundation/CIPs/pull/349/files#diff-3123ac21b2252bb3949c1fe0339517643e48d548550dc5794c1906e80b430a1aR49 |
@SebastienGllmt Note that according to the CDDL RFC:
I interpreted this as meaning that the code at the top of this issue should stay the same as that's only for mandatory fields. For optional fields we would use the default value though. The governance cip uses it on an optional field. I can't tell for the byron one since I only have the one that doesn't mention it. |
Adds .default support to typenames (`foo = bar .default baz`) and to map fields (`foo = { ? 1 => bar .default baz }`). This is not applied into nested contexts e.g.: ``` foo = uint .default 2 bar = { * str => foo } ``` as how this should be handled is extremely ambiguous. Should this result in an extra encoding variable which is a map e.g. `default_included: BTreeSet<K>` and having the behavior be to omit it if it's not included in this encoding var and it's equal to the default ? As per the CDDL RFC we only apply it to optional fields: ``` This control is only meaningful when the control type is used in an optional context; otherwise, there would be no way to make use of the default value. ``` We support encoding preservation for round-tripping i.e. if a default value is explicitly present it will remain explicitly present. With `preserve-encodings=false` it will be omitted if the value present is equal to the default value. No changes were done with canonical encodings as the RFC doesn't seem to mention how that should be handled as canonical encodings are specified in the CBOR RFC not the CDDL one, and `.default` is only present in the CDDL one. It's that possible we could omit fields equal to the default if needed but we need to confirm this first. Optional fields with `.default` are no longer encoded as `Option<T>` but instead just `T` now which should help with usability. The field will default to the default via `new()` and deserialization. Fixes #42
Currently, when a required field is missing we generate code that looks like this
I believe for
.default
, all the code is generated exactly as it is now except we change this error to instead return the default value.Additionally, on serialization, if the field is equal to the default value we just omit it from the cbor notation
This is used in one place in the byron CDDL spec (although
byron.cddl
does not mention it)The text was updated successfully, but these errors were encountered: