feat: integer validation precision #181

[kstasik]

Proper integer validation support

[tobz]

@GREsau Sorry to pester, but this would be useful to merge.

The integer type has been supported since draft-02, seemingly, so it's safe to add from that perspective, and represents a feature that would only serve to allow better parity between the annotated Rust types and the resulting schema.

(Also interested in chatting about potentially becoming an official maintainer for this crate, as it is the cornerstone of a large feature we've implemented in a work product and we have a vested interest in supporting/improving it... but that's tangential to the ask here.)

[GREsau]

Is the purpose of this PR just to serialise numbers without the decimal point when they're integers? If so, that could be achieved more simply (and without introducing breaking changes) by adding a #[serde(serialize_with = "...")] attribute on those fields that checks whether the number can be losslessly converted to an i64, and if so convert it and serialize via serialize_i64.

[tobz]

The schema validation specification specifically describes an integer type, and the schema core specification encourages implementors to not encode integers with a fractional component. Taken together, these seem like a strong indication that just naively encoding all integers and floating-point numbers the same way, and treating them both as the number type, is not in line with the spirit of the specification, even if the approach taken by schemars is technically compatible.

A solution based on #[serde(serialize_with = "...")] would technically work, but is certainly pushing the work to the users of the library for what should, again, be happening in schemars in line with the spirit of the specification.

[GREsau]

...the schema core specification encourages implementors to not encode integers with a fractional component.

I didn't know that, that's useful info - thanks!

A solution based on #[serde(serialize_with = "...")] would technically work, but is certainly pushing the work to the users of the library for what should, again, be happening in schemars in line with the spirit of the specification.

I'm not sure what you mean by this - I was suggesting altering schemars like this:

pub struct NumberValidation {
    /// ...
    #[serde(skip_serializing_if = "Option::is_none", serialize_with="some_new_fn")]
    pub multiple_of: Option<f64>,
    /// ...
    #[serde(skip_serializing_if = "Option::is_none", serialize_with="some_new_fn")]
    pub maximum: Option<f64>,

so there would be no change required for users of schemars

[kstasik]

IMO integer format should be enforced only for integers - not floating point numbers. Taking your approach we would convert threshold of 1.0 to 1 in case of floats.

I thought that current approach will be the most elegant way. If we assume that most of users of this crate are using derive feature it should not be a breaking change for them...