Ability to attach macros to generated types and methods

[HonQii]

It would be nice to be able to add macros to the generated Schema and API requests in order to extend the functionality, e.g. all of my request return structures have an optional error field, so if I could add a macro that would allow me to extend the support for a protocol for them, I could easily handle the error uniformly

[simonjbeaumont]

@HonQii could you elaborate a little on what you'd like to see? You can currently write extensions on the types generated and conform them to protocols that you define. Are you asking for the protocol conformance to be automatically added for you by the generator, potentially by specifying a macro you'd like to run in the generator config?

Maybe you could provide a quick snippet of how you'd like the generated code to be different.

[czechboy0]

Maybe @HonQii means that they could configure some macro name to be automatically attached to all generated types, similar to how we allow adding additional imports? But the user would still need to provide the macro implementation.

(Which is an interesting idea that would indeed provide quite a lot of flexibility for sufficiently motivated adopters.)

[HonQii]

Maybe @HonQii means that they could configure some macro name to be automatically attached to all generated types, similar to how we allow adding additional imports? But the user would still need to provide the macro implementation.🔄  ❓

(Which is an interesting idea that would indeed provide quite a lot of flexibility for sufficiently motivated adopters.)🔄  ❓

Right, what I mean is that I can configure macros to the generated Schema as well as the Client so that I can do some wrapping. An example:

// Each of my request response structures will have an error field with a message and code if there is an error
struct BaseResponse {
      var error: Error? // empty if there is no error.
}

Normally I would need to define a protocol for all structures to follow, and then I could handle these errors consistently. But in the case of autogeneration, I think it's more appropriate to use a macro for this purpose

Similarly, I need a layer of encapsulation for each request in the client to handle exceptions, which can also be accomplished using a macro

[czechboy0]

Can you be even more specific here, for example use a simple OpenAPI document, generate code with it, and then outline what exact changes you'd like to see in the generated code? I'm still not entirely sure I understand.

[simonjbeaumont]

// Each of my request response structures will have an error field with a message and code if there is an error
struct BaseResponse {
      var error: Error? // empty if there is no error.
}

OOI, are you the author of this document? Because, if so, for this example, you could have the generated code make use of shared types by writing this in the OpenAPI document itself. For example, you can make use of of a common type in #/components/schemas, or you could define a shared response in #/components/responses, or you could try and combine these with an allOf¹.

Concretely, if you make use of references in the OpenAPI document, then the generator will use a single type. This allows for you to write extensions on this common type once.

Footnotes

1. https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md#composition-and-inheritance-polymorphism ↩

[HonQii]

Can you be even more specific here, for example use a simple OpenAPI document, generate code with it, and then outline what exact changes you'd like to see in the generated code? I'm still not entirely sure I understand.您能否在这里更具体一点，例如使用一个简单的 OpenAPI 文档，用它生成代码，然后概述您希望在生成的代码中看到哪些确切的更改？我仍然不完全确定我是否理解。

For example, I'm using the Combine framework to encapsulate a lot of UI components, so I'd like to be able to return web requests through the Publisher, and I'm now generating my own batch of code using the Plugin, which is formatted as follows:

func getMyInfo(_ query: Components.Schemas.GetMyInfoReq) -> AnyPublisher<Components.Schemas.GetMyInfoResp, Error> {
        Future { promise in
            Task {
                do {
                    let resp = try await self.filterSuccess(await self.client.getMyInfo(.init(body: .json(query))))
                    promise(.success(resp))
                } catch {
                    promise(.failure(error))
                }
            }
        }
        .eraseToAnyPublisher()
    }

If I could support macros when generating swift-openapi-generator, I could generate the methods directly from the macros, and instead of having to convert the results using the filterSuccess method, I could just make each structure in the Schema adhere to a certain protocol, and use Combine's filter function to handle the errors.

[HonQii]

// Each of my request response structures will have an error field with a message and code if there is an error
struct BaseResponse {
      var error: Error? // empty if there is no error.
}

OOI, are you the author of this document? Because, if so, for this example, you could have the generated code make use of shared types by writing this in the OpenAPI document itself. For example, you can make use of of a common type in #/components/schemas, or you could define a shared response in #/components/responses, or you could try and combine these with an allOf1.OOI，你是本文档的作者吗？因为，如果是这样，对于此示例，您可以通过将其编写在 OpenAPI 文档本身中来让生成的代码使用共享类型。例如，您可以在 中使用 中的通用类型，也可以在 中定义共享响应，或者可以尝试将这些响应 #/components/schemas 与 allOf 1 . #/components/responses

Concretely, if you make use of references in the OpenAPI document, then the generator will use a single type. This allows for you to write extensions on this common type once.具体来说，如果使用 OpenAPI 文档中的引用，则生成器将使用单个类型。这允许您在此常见类型上编写一次扩展。

1. https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md#composition-and-inheritance-polymorphism ↩

Sorry, I didn't write it.

[czechboy0]

If I understand correctly, you'd be interested in being able to use a macro to generate a variant of every client method that uses Combine, like you outlined above?

If so, that seems very similar to the "add async variant" macro here: https://github.com/apple/swift-syntax/blob/main/Examples/Sources/MacroExamples/Implementation/Peer/AddAsyncMacro.swift

The question is where exactly the generator would add the @UserSpecifiedMacro macro, probably in the extension, so that the macro could emit an implementation (couldn't be on the func declaration in the protocol). I think that could work, and can be done post-1.0 as a non-breaking change, as this would be fully opt-in through the config file, similar to additionalImports.

[czechboy0]

Okay, renaming this issue to track the general desire to attach macros to generated types and functions.