Open Gutawer opened 1 month ago
Maybe a dumb question, but can you cast with as f32
on the Rust side? I don't think there are any feature flags which change the behaviour of Ciborium, and I fear that being lose with f32
vs u32
could break things (if I'm understanding what you're asking).
can you cast with
as f32
on the Rust side
Yes, but that'd require putting a wrapper type that can be converted like that in every place I want to accept an f32
, and moreover, I'd like to turn my work into a library others can use, and I'd like to make the "path of least resistance" the one that exhibits the nicest behavior.
I don't think there are any feature flags which change the behaviour of Ciborium
Yep fair, to be clear I'm asking for a runtime parameter, not a feature flag. I guess what that'd map to is a new from_reader_*
function, but in case more requests like this come in in the future, it may be more future-compatible to provide a from_reader_with_options
function, taking in a DeserializerOptions
struct that uses Default
and the builder pattern.
Then the default behavior would be the current one (which makes the most sense in pure Rust scenarios) but more lenient behavior can be opted into on a per-call basis.
Also just to be as clear as possible, this is all in the context of a serde #[derive(Deserialize)]
.
Is there an existing issue for this?
Description
Apologies if there's already a way to do this outside of the library, I'm not massively familiar with the serde ecosystem yet.
I'm currently using this library as a "wire format" for a WASM plugin to the typst typesetting/programming language. Generally the experience has been really good but I'm running into a minor little thing which I'd like to know if there's a way around. Namely, the typst language always allows you to parse in an integer where a float is expected, but I don't see an easy way to replicate that with this library. Doing
cbor.encode(1)
in typst (which usesciborium
internally) and then trying to decode it intof32
on my Rust side givesSemantic(None, "invalid type: integer `1`, expected float")
, creating unexpected behavior given the context.That behavior makes perfect sense for a Rust-encode, Rust-decode application, so I'm not asking for it to be changed. I'd just like if there was an optional flag for enabling this behavior for when it makes sense to - for example I'd also expect input encoded from Python to have the same expectation, since ints implicitly coerce to floats there too.
I'm happy to look at implementing this if it'd be accepted.
Acceptance Criteria
No response
Suggestions for a technical implementation
No response