Support case-insensitive string enums

[CalebKierum]

Motivation

I am stealing this request entirely from this request which resulted in a change to the Go cli.

Given the following enum spec:

enum:
- HDD
- SSD
- NVME
type: string

The Swift client generator will generate an enum that does strict == comparisons, so if the specified API returns NVMe instead of NVME, the response will fail validation because "NVMe" != "NVME".

In my case specifically I needed it for state codes where someone may write "WA" or "Wa"

Proposed solution

The Java generator supports a useEnumCaseInsensitive option; The Go generator supports a option via the x-go-enum-ci extension.

When that option is enabled, the generator will use case-insensitive equality checks for string enums. Copying that feature into the Swift generator would enable generator users to opt in to case-insensitive comparisons for string enums.

Alternatives considered

Certainly can smooth this out by cleaning up server side implementation. Have tried a spec like

    StateOrProvince:
      type: object
      oneOf:
        - $ref: '#/components/schemas/KnownStateOrProvince'
        - $ref: '#/components/schemas/UnknownStateOrProvince'

    UnknownStateOrProvince:
      type: string

    KnownStateOrProvince:
      type: string
      enum:
        - AL
        - AK
        - AZ

But while that fixes parsing it does not allow me to recognize "Wa" as .WA.

Additional information

No response

[czechboy0]

Hi @CalebKierum,

there are a few workarounds you could look into before we consider adding this option to the generator.

Try to write a ClientMiddleware that collects the body bytes, parses it into JSON (I presume that's what you're using), and then normalizes all of the places where you use these state enums to match the casing (in your case, I guess uppercasing them). Then the middleware would encode it back into data and pass it along, which then makes the generated code successfully parse the enum.

This approach isn't super performant, but can unblock you while we discuss other possibilities, or until the server fixes their conformance to their OpenAPI doc.