Can't add CaseIterable on Apollo-generated enum

[guillaume-roux]

Hello,

We're trying to iterate on the Enum generated from the schema, so we've tried to add CaseIterable to it but Swift won't allow that due to the __unknown() case in the Enum.

Is there a way to iterate on the enums values apart from parsing the schema.json again?
Could Apollo maybe generate an AllCases constant holding all-bar-unknown value cases so we can get that rather than resort to CaseIterable?

[zigfreid5]

I implemented a temporary workaround based on some other suggestions for similar issues.
You can add CaseIterable conformance in an extension and still validate proper implementation by using something like this:

extension Gender: CaseIterable {
    public static var allCases: [Gender] {
        @available(*, unavailable)
        func _assertExhaustive(for gender: Gender) {
            switch gender {
            case .male, .female, .other, .notProvided, .unknown:
                break
            }
        }
        return [.male, .female, .other, .notProvided]
    }
}

The nested function is marked as unavailable so you can't call it, but it will break your build if the schema changes and messes with the enum cases. As long as you keep the array of cases updated, this allows you to have your CaseIterable and ignore the unknown case.

The problem with the codegen goes deeper than CaseIterable, however, and I think a proper fix would be to add an option to skip generation of unknown cases for enums altogether.

Another issue I came across is that I had been initializing enum cases with the rawValue init, but if the string value isn't an exact match, you end up with an unknown("value") instead of what you expected. It should be a failable initializer and produce nil, but because of the unknown case and generated initializer, you will never get nil. In my opinion, this is bad implementation and should be fixed.

[Mountainbrussells]

I also believe adding caseiterable to the generated enums would be a good idea, I used the same workaround as @zigfreid5

[designatednerd]

I'm fairly new so I have to make sure that we're not doing anything too nuts that would make non-automatic CaseIterable conformance impossible, but CaseIterable is my jam and I'd love to make everything conform to it.

[designatednerd]

Hi! Tooling PR 1441 adds generated CaseIterable conformance for all known cases. Please head over there and let me know if you see any problems with that implementation!

[designatednerd]

Built-in CaseIterable support for known cases shipped with 0.14.0!

[designatednerd]

Do note that if you used @zigfreid5's workaround, you'll need to remove it since it'd be a redeclaration of CaseIterable conformance once you upgrade to 0.14.0