CaseIterable synthesized conformance should let me override the collection type

It would be fantastic if CaseIterable synthesized conformance would work in the event that I manually declare the AllCases typealias, as a type that is a Collection and ExpressibleByArrayLiteral. The use-case I'm thinking here is

public enum Foo: CaseIterable {
    public typealias AllCases = Set<Foo>
    case one, two, three
}
3 Likes

You know, we probably should allow it. (And I'm not sure the auto-derivation even contemplates this possibility right now; the error we're producing—"protocol 'CaseIterable' is broken; cannot derive conformance for type 'Foo'"—is meant to indicate that the standard library's definition of CaseIterable doesn't look the way the compiler expects it to.)

I'm not sure if this needs an evolution proposal; it might be small enough to be considered a bug fix.

Ok I filed a ticket as SR-8777.

This will have to be done with some cleverness, as it is not a source-compatible change to add an associated type to a protocol that has none.

There already is an associated type constrained to Collection where Element == Self; it’s just that the synthesis code in the compiler assumes that if you haven’t written an allCases manually, you also haven’t specified the AllCases associated type, and it can set it to Array<Self>. That’s why I think this might be fixable without a proposal—it’s just expanding the synthesis to a straightforward case.

1 Like