Advice regarding nullable refs?

### Question

Hello,

I'm writing a client with an openapi.yml that frequently uses nullable ref properties, as below:

```yaml
// Technique 1
my_field:
nullable: true
allof:
- $ref: '#/components/schemas/MyField'
```

An alternative technique, AFAIK, is:

```yaml
// Technique 2
my_field:
oneOf:
- $ref: '#/components/schemas/MyField'
- type: 'null'
```

With both techniques, the generated code is not quite easy to deal with, both when decoding responses or encoding requests. The generated payload is a struct that has a non-semantic `value1` property, or an enum that does not expose any accessor for extracting its non-null value.

```swift
// Technique 1
public struct my_fieldPayload: Codable, Hashable, Sendable {
public var value1: Components.Schemas.MyField
public init(value1: Components.Schemas.MyField) {
self.value1 = value1
}
}

// Technique 2
@frozen public enum my_fieldPayload: Codable, Hashable, Sendable {
case MyField(Components.Schemas.MyField)
case case2(OpenAPIRuntime.OpenAPIValueContainer)
}
```

We're far from the expected Swift optionals. The struct generated by the technique 1 is surprisingly shallow.

Did any member in the community meet the same problem? Is there any workaround? Or a better YAML technique for specifying a nullable ref, while preserving good Swift ergonomics? Maybe I'm just holding it wrong?

Begin with the two nullable-reference schemas in openapi.yml and compare the generated Swift payloads shown in the report. Check the generator's current handling of these OpenAPI forms and any existing guidance or tests. The issue is resolved when a supported schema workaround or a concrete, agreed change for Swift optional ergonomics is documented.

Written by the indexing model from the issue text.