You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With edn-literals recently adopted by the CBOR WG, I'd love to see support for that in here. Implementing cri"" won't make much sense yet because CRI is not finished (when it is, I can provide the workhorse crate), but dt"" seems stable enough.
Like EDN embedded CBOR, this can be ingested without any extra processing, but producing it will need decisions (with "we don't produce it" being a viable first step). The same mechanism that would resolve #132 could be used to eventually produce them -- it'd just need generalization (because now suddenly a float or integer can either be encoded directly with a bitwidth, or the dt EDN literal).
The text was updated successfully, but these errors were encountered:
With edn-literals recently adopted by the CBOR WG, I'd love to see support for that in here. Implementing cri"" won't make much sense yet because CRI is not finished (when it is, I can provide the workhorse crate), but dt"" seems stable enough.
Like EDN embedded CBOR, this can be ingested without any extra processing, but producing it will need decisions (with "we don't produce it" being a viable first step). The same mechanism that would resolve #132 could be used to eventually produce them -- it'd just need generalization (because now suddenly a float or integer can either be encoded directly with a bitwidth, or the dt EDN literal).
The text was updated successfully, but these errors were encountered: