Support recursive types

[scsinke]

Currently the package does not support recursive types. Should this be possible? Maybe I'm doing something wrong. otherwise, I would propose to add this constraint in the docs. I have this use case due to Server Driven UI. This results in components or actions that can be embedded in each other.

Errors:

• Value type 'x' cannot have a stored property that recursively contains it
• Value type 'x' has infinite size

[czechboy0]

Thanks for filing the issue, we'd certainly accept a contribution of support of recursive types.

Could you please add a snippet of OpenAPI that uses it in YAML, and how you imagine the generated code would change? That'll help us discuss the desired solution.

[knellr]

We are looking at migrating from our own hand-rolled code generation to this library, and for some of our APIs we are also encountering this issue.

Here's an example schema with recursion (involving only one model):

Recursion:
  properties:
    recursion:
      "$ref": "#/components/schemas/Recursion"
  type: object

In our existing code generator we break out of the dependency cycles by wrapping the property in a Box:

    public final class Box<Wrapped> {
        public var value: Wrapped
        public init(_ value: Wrapped) {
            self.value = value
        }
    }

    extension Box: Encodable where Wrapped: Encodable {
        public func encode(to encoder: Encoder) throws {
            try value.encode(to: encoder)
        }
    }

    extension Box: Decodable where Wrapped: Decodable {
        public convenience init(from decoder: Decoder) throws {
            let value = try Wrapped(from: decoder)
            self.init(value)
        }
    }

    public struct Recursion: Codable, Hashable {
        public let recursion: Box<Recursion>?
    }

[scsinke]

I don't know if this can solve the issue. But maybe we can make use of the indirect keyword? https://www.hackingwithswift.com/example-code/language/what-are-indirect-enums

[czechboy0]

Seems that indirect can only be used on enums, not structs.

Before we consider the explicit Box approach, I'd like to see if there's another recommended way in Swift to solve this.

[scsinke]

Hereby a simplified spec we use. For the full openAPI spec we use. check this link.

{
  "openapi": "3.0.2",
  "components": {
    "schemas": {
      "Action": {
        "anyOf": [
          {
            "$ref": "#/components/schemas/PromptAction"
          }
        ]
      },
      "PromptAction": {
        "type": "object",
        "properties": {
          "type": {
            "type": "string",
            "enum": [
              "PROMPT"
            ]
          },
          "prompt": {
            "$ref": "#/components/schemas/Prompt"
          }
        },
        "required": [
          "type",
          "prompt"
        ]
      },
      "Prompt": {
        "anyOf": [
          {
            "$ref": "#/components/schemas/DialogPrompt"
          }
        ]
      },
      "DialogPrompt": {
        "type": "object",
        "properties": {
          "type": {
            "type": "string",
            "enum": [
              "DIALOG"
            ]
          },
          "title": {
            "type": "string"
          },
          "message": {
            "type": "string"
          },
          "confirmButtonTitle": {
            "type": "string"
          },
          "cancelButonTitle": {
            "type": "string"
          },
          "confirmAction": {
            "$ref": "#/components/schemas/Action"
          }
        },
        "required": [
          "type",
          "title",
          "message",
          "confirmButtonTitle",
          "cancelButonTitle",
          "confirmAction"
        ]
      }
    }
  }
}

[scsinke]

I think there are three options as far as I can tell.

• Make it a class. But this does make it a bit less swifty because we're not using structs

class Recursive {
    let value: Recursive
}

• Make an indirect enum.

enum Recursive<Element> {
  indirect case value(Recursive<Element>)
}

• Use the box as stated above. So it can be used inside a struct. This can be a bit simplified by maybe adding a property wrapper.

[czechboy0]

Yeah, that sounds about right. Ideally, we could constrain this as much as possible, to:

• direct nesting
• the property must be optional

And we could use a property wrapper.

We already have the concept of a TypeUsage that represents a type being wrapped in an optional, an array, etc. I guess we could think of an "indirection box" as just another type of wrapping here, make it Sendable, Codable, etc.

It's important we limit how many places in the generator have to make explicit decisions based on this.

Might be worth for someone to prototype this and see what else might get hit.

[scsinke]

@czechboy0 If you can give me some pointers on how and where to start prototyping. Will try to play around with it.

[czechboy0]

Hi @scsinke, sure!

TypeUsage is defined here:

swift-openapi-generator/Sources/_OpenAPIGeneratorCore/Translator/TypeAssignment/TypeUsage.swift

Line 43 in 6b11135

fileprivate enum Usage {

The need for boxing could be represented as another case in the type usage internal enum.

The need for it would be calculated for the property schema, probably somewhere around

swift-openapi-generator/Sources/_OpenAPIGeneratorCore/Translator/TypeAssignment/TypeAssigner.swift

Line 234 in 6b11135

private static func _typeUsage(

, if the parent type and the property type are the same.

Then, we'd probably need to adjust the struct generation logic to include the extra boxing when requested:

swift-openapi-generator/Sources/_OpenAPIGeneratorCore/Translator/CommonTranslations/translateStructBlueprint.swift

Line 21 in 6b11135

func translateStructBlueprint(

Would be great if the box could be represented as a property wrapper somehow.

But that's just one idea, you'll see what looks good when you're prototyping it, feel free to tag me on a PR with a proof of concept, and we can discuss more.

[czechboy0]

Another way to implement this would be:

• The type that needs to be "boxed" (aka is part of a cycle) would have a slightly different implementation under the hood: it'd still be a struct publicly, but internally would hold a class and use CoW. So the adopter would not know whether it's a plain old struct, or this "boxed" struct, but it'd break the cycle and allow for both direct and transitive recursive types.
• Deciding which type needs to be boxed is a separate algorithm, ideally we want to box as few types as needed to break all the cycles in a single document, but an algorithm that boxes all types (func needsBoxing(...) -> Bool { true }) would be an okay starting point, and try to make it more efficient from there.

If someone wants to pick this up, it could make sense to PR these bits independently, e.g. the algorithm first, then the changes to the generator.