derive ToSchema fails for types using generics

[jayvdb]

Using #[derive(ToSchema)] on types like geo_types::Coord fails because it uses generics

e.g. jayvdb/geo@9b2c876

pub struct Coord<T: CoordNum = f64> {
    pub x: T,
    pub y: T,
}

becomes

      "Coord": {
        "type": "object",
        "required": [
          "x",
          "y"
        ],
        "properties": {
          "x": {
            "$ref": "#/components/schemas/T"
          },
          "y": {
            "$ref": "#/components/schemas/T"
          }
        }
      },

The basic fix for this would be to recognise the T: CoordNum = f64, and use f64 for each T, and also fail if the struct was designed using T: CoordNum without any default type for T, as in that case utoipa has a lot more work to do in order to know what CoordNum might be.

[juhaku]

Oh, the scenario with generics having = DefaultType have not been implemented. Support for this perhaps could be implemented, but that would only make it support the DefaultType and when used with some else the generated schema does not match to the actual schema. That's why with generics there is a need to use #[aliases(...)] but in the case of geotypes I am not convinced that it actually would work. utoipa needs to know possible types upon type creation and not when it is used with.

Perhaps the manual implementation is better, but there is the overhead of double declaring the properties. I posted a example of manual implementation with PartialSchema to here #566 (reply in thread).

[johnperry-math]

@jayvdb I had an issue like this, only it involved core::ops::range::RangeInclusive. My solution was to create a new struct for the sake of annotating it and assign a value_type. Something like this for your case:

#[allow(dead_code)]
#[derive(ToSchema)]
pub struct Coord64 {
   pub x: f64,
   pub y: f64,
}

#[derive(Serialize, Deserialize, ToSchema)]
pub struct Client {
   #[schema(value_type=Coord64)]
   field: Coord<f64>,
   // ...
}

[juhaku]

Apart from that there are few alternatives one might consider when creating ToSchema implementation for type of external crate #507 (comment).

[jayvdb]

Created #588 showing some of the limitations and workarounds for generics.

[jayvdb]

My colleague @joaommartins did some work on improving ToSchema to handle generics, before we started using schema_with, and unfortunately before f7dfff8 so the commits are not easily rebased. That said, if anyone is interested in pursuing this, they may be instructive to some degree. The commits are at franklin-ai@d135fec and franklin-ai@fa3586f

[juhaku]

There is now new implementation for generics coming up in #1034 which should solve the issue with aliases approach.