Repository navigation
Add ability to attach protocols to generated models #573
Description
Motivation
We need all of our models generated by swift-openapi-generator to comply with protocols like Equatableor Identifiable to work with our overlaying architecture. Manually extending each generated model to conform to these protocols is insufficient and cumbersome, especially as the number of models increases.
Proposed solution
Add a feature to the swift-openapi-generator that allows specifying which protocols the generated models should conform to. This could be implemented as a configuration option in the generator, enabling automated protocol conformance during the model generation process.
Alternatives considered
The current workaround is manually extending each generated model, like so:
extension ModelA: Equatable {}
extension ModelB: Equatable {}
extension ModelC: Equatable {}
extension ModelD: Equatable, Identifyable {
var id: Int
//...
}However, this approach is not scalable and becomes unwieldy as the number of models grows.
Additional information
If there is already an existing feature to achieve this, i apologize for the oversight and kindly request guidance to the relevant documentation. I could not find any reference to such a feature in the current documentation.
References:
Identifiable Documentation
Equatable Documentation
Thank you for considering this request.
Activity
czechboy0 commentedon May 17, 2024
Hi @armintelker,
all generated types already conform to
Equatable, as we generate theHashableconformance (which includesEquatable).Identifiable, on the other hand, is tricky, as it's not clear what theidproperty should return for arbitrary schemas. What would be your expectation?armintelker commentedon May 17, 2024
Hey, thanks for the quick response.
I have overseen that the DTO is already conforming to Hashable. This makes, of course, everything a lot easier. So my request gets kind of needless.
Indeed the
Identifiableprotocol suggestion would be more like a "nice to have".I could imagine that the generator could add the
Identifiableto the model as soon it sees a propertyidexists that also conforms to the constraint of the protocol.czechboy0 commentedon May 17, 2024
In theory yes, but my first instinct is that this would be considered out of scope of an OpenAPI generator. I think a separate build plugin that processes your Swift code and adds
Identifiableto any struct that has anidproperty would be more appropriate, and more maintainable. This is a feature that would be useful outside of the OpenAPI context.simonjbeaumont commentedon May 21, 2024
This is similar to #383, where could conceivably attach arbitrary conformances or macros that are stated in the config file and it be up to the adopter to ensure these are available in their project.
It wouldn't be too different from the ability we have know to express
additionalImports.czechboy0 commentedon May 22, 2024
That's true, @simonjbeaumont, and the macro itself would contain the logic for how to e.g. implement
Identifiable, instead of the generator having to know how to do it. I like that.shadone commentedon Jun 16, 2024
+1 to this. In my use case it would also be useful to have ability to add Identifiable conformance to some types. There is literally no other way to do this - I have a library that uses swift-openapi-generator to generate the type and expose them publicly.
It would be nice if Swift allowed to add public conformance to a protocol in an extension:
Unfortunately this is not possible in Swift, so the only solution I can see is to solve it in the openapi generator.
czechboy0 commentedon Jun 16, 2024
Hi @shadone,
does this work?
(without the public modifier on the extension, only on the id property).
shadone commentedon Jun 16, 2024
<
deleted previous content> I completely misunderstood what czechboy0 was sayingThat work indeed, thanks @czechboy0 ! To be honest I had no idea this is possible, despite years of writing Swift code. And to be honest I do not understand why this works (does the SortType publicly conform to the protocol here or just the "shape" of the protocol)
But it works great, thanks!
czechboy0 commentedon Jun 17, 2024
I believe the visibility of the conformance is always derived from the visibility of the extended type and the protocol, i.e. there is no way to privately conform a public type to a public protocol.
But to get more details, starting a thread on the Swift Forums might be a good next step, if you're interested in the lower level compiler details.
czechboy0 commentedon Oct 29, 2024
I believe we arrived at a reasonable workaround, so closing. Please reopen if there are new use cases which cannot be addressed with a hand-written extension, and would require changes to the generator.