[Feature]: Optionally accept integers where floats are expected

[Gutawer]

Is there an existing issue for this?

• I have searched the existing issues

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 uses ciborium internally) and then trying to decode it into f32 on my Rust side gives Semantic(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

[rjzak]

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).

[Gutawer]

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.

[Gutawer]

Also just to be as clear as possible, this is all in the context of a serde #[derive(Deserialize)].

[hoxxep]

@Gutawer does deserialize_with achieve what you're looking for? Avoids a wrapper type, and only requires tagging each field with a serde attribute to point to your custom deserialize method for that field.