duplicates:

• SR-8776 Confusing error with broken CaseIterable conformance
• SR-8777 CaseIterable synthesis should work in the presence of a manual AllCases typealias

relates to:

• SR-8776 Confusing error with broken CaseIterable conformance
• SR-8777 CaseIterable synthesis should work in the presence of a manual AllCases typealias

Issue Description:

Crasher

// error.swift
enum Directions : CaseIterable {
  case north
  case south
  // The user customized the `AllCases` requirement but not `allCases`.
  typealias AllCases = UnsafeBufferPointer<Directions>
}

Error:

error.swift:1:6: error: type 'Directions' does not conform to protocol 'CaseIterable'
enum Directions : CaseIterable {
     ^
error.swift:1:6: error: protocol 'CaseIterable' is broken; cannot derive conformance for type 'Directions'
enum Directions : CaseIterable {
     ^

Explanation

CaseIterable has two requirements:

public protocol CaseIterable {
  associatedtype AllCases: Collection
    where AllCases.Element == Self
  static var allCases: AllCases { get }
}

The condition for deriving conformances to CaseIterable currently doesn't take into account whether other requirements have been user-defined/customized. (This is true for all derived conformances, in general.)

The code synthesis for allCases creates an ArrayExpr (from this commit). This is problematic if AllCases is defined to be a collection that is not ExpressibleByArrayLiteral, as in the crasher program above.

Possible solutions

One solution is to "can derive conformances" condition for CaseIterable so that synthesis is possible only if no requirements have been user-customized. It may be useful to generalize this condition for all protocol derived conformances though - I think it's common that synthesis is intended only when no requirements are customized.

Another solution is to change the synthesis condition to account for whether AllCases conforms to ExpressibleByArrayLiteral. This seems like a weird, undocumented "point of customization" for users though.