Schema component named Request generates ambiguous code

[js]

Gave create-api a quick whirl with our schema, looks like having a type named Requestconfuses the compiler with the Request<Response> from Get: API/Sources/Paths.swift:31:57 Cannot specialize non-generic type 'Request'

as the compiler tries to use the following generated struct from Entities.swift instead of Get.Request<Response>:

public struct Request: Codable {
    public var reason: String?

    public init(reason: String? = nil) {
        self.reason = reason
    }
}

schema snippet:

....
  "components":
          "Request": {
        "type": "object",
        "properties": {
          "reason": {
            "type": "string",
            "nullable": true
          }
        },
        "additionalProperties": false
      },
      "RequestData": {
        "type": "object",
        "properties": {
          "id": {
            "type": "string",
            "nullable": true
          },
          "type": {
            "type": "string",
            "nullable": true
          },
          "attributes": {
            "$ref": "#/components/schemas/HandleDiscountEventAttributes"
          }
        },
        "additionalProperties": false
      },
...

[LePips]

This is definitely related to #84, but this isn't necessarily a bug. Get.Request is the structure used to create requests, so it makes sense that if a schema object named Request would conflict. The current consensus of #84 is that the structure to create a request would be generated by CreateAPI, so the default Request structure would probably always conflict.

Probably the only solution is to use rename.entities.

However, we could probably display a warning if a schema object name would conflict.

[js]

I don't necessarily disagree with it not being a bug, but it did initially confuse and disappoint me slightly so I can imagine the few others hitting this share that sentiment :) I was not aware of rename.entities, will look into that.

One solution that comes to mind is to always call it as Get.Request in the generated code? As the generated code lives in a separate package the risk of type conflicts is always there when relying on Swifts namespace/module resolver

[devraj]

Came across the same issue when interacting with the Github API. I found that the code was generating certain models twice over. I am probably more inclined to go back to using Get and write the models myself for my use cases.

@kean your examples on the Get docs refer to OctoKit as the example. Generating the client using api.github.com.2022-11-28.json from their schema publications complains about the Assignee struct, wondering if you have noticed anything similar?

[liamnichols]

At the very least, it would be good for CreateAPI to warn about naming conflicts as we probably can tell when this might happen 👍

As for renaming Request to Get.Request in generated references, that would cause issues with people who import the Request type from a different dependency (or don't import it at all and define it inline). It's something that #84 could help with for sure though.