Add Hashable for Struct

[maoyama]

Resolves #9030

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master, 5.1.x, 6.0.x
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.
  @jgavris (2017/07) @ehyche (2017/08) @Edubits (2017/09) @jaz-ah (2017/09) @4brunu (2019/11)

[wing328]

@maoyama thanks for the PR. What about adding an option (e.g. hashableStruct) to add x-swift-hashable to all models in postProcessModels if x-swift-hashable is not yet defined in the model?

Ref: https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/java/org/openapitools/codegen/CodegenConstants.java#L133

[maoyama]

@wing328 I didn't want to add more options and make it more complicated for the user. I like the simple specs by this PR.

[wing328]

Understood. Let's see if the Swift technical committee has a different option on this as I do not know if everyone likes hashable struct.

[wing328]

Another use case worth considering is that a user wants all models except a few models to extends hashable. An option I described above can achieve that.

[4brunu]

I don't see any downside in making all the models conform to Hashable.
For me we can go with all models conform to Hashable and if an issue appears to someone we can introduce a flag to disable some cases.

[wing328]

OK. Let's go with this and add an option if needed later.

[fl034]

Hey guys @4brunu . I've experienced a downside of this feature. I have many custom implementations of Hashable that seem to be ignored now, since the model has a synthesized implementation.
In my custom implementations I exclude for example timestamps like "updatedAt".

So for me it will be crucial to be able to control this feature. For me it would be best to be able to control this at model-level. Like with x-swift-hashable or x-swift-disable-hashable.

We could also have a configuration flag to set the default behavior.

[4brunu]

A configuration flag to control the behaviour seems a good option to me.
@fl034 could you please open a PR with this?

[fl034]

Sorry @4brunu I don't have resources for it this time. My workaround was to downgrade to 5.1.0.
I added an issue to track it. #9473

[maoyama]

@fl034 @4brunu

I have many custom implementations of Hashable that seem to be ignored now, since the model has a synthesized implementation.

I want to know more about this custom implementation of Hashable that seem to be ignored.
I think that we can exclude the specified property by custom implementation of Hashable like below:

// Custom implementations of Hashable
extension Animal {
    static public func == (lhs: Animal, rhs: Animal) -> Bool {
        return lhs.className == rhs.className
    }

    public func hash(into hasher: inout Hasher) {
        hasher.combine(className)
    }
}

// Generated Model
public struct Animal: Codable, Hashable {
    public var className: String
    public var color: String? = "red"

    public init(className: String, color: String? = "red") {
        self.className = className
        self.color = color
    }
}

(If this feature has a downside, we need an option to control its behavior.)

[fl034]

@maoyama I suppose when the extension is in the same file, the custom implementation is used. But this is not applicable for generated code files, of course.

In my case I even get a compiler warning, that my implementations will be ignored.

[maoyama]

@fl034 Thank you for your reply.
I understood that we need an option to control its behavior.

Here are the results of the custom implementation I've tried:

• Hashable can be custom implementation in the same module, not limited to the defined file.
• Hashable cannot be custom implementation with different modules. (Equatable is possible)

I can open a PR with adding options.

[4brunu]

@maoyama a PR is welcome 👍