On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote: > My objection to the "ValueEnumerable" design--especially in its generalized > form here (versus "CaseEnumerable")--is that the protocol's semantics (and, > we'll recall, protocols in Swift must offer semantics that make possible > useful generic algorithms) are so broad as to be little more than essentially > what it means to be a type.
Thank you for writing this up Xiaodi. I completely agree with you that “CaseEnumerable” is a better name for this: it is more specific and purposeful and make it more clear what the purpose and scope is. Your later suggestion of “Enumerable” seems to broad and potentially confusing to me. Tying it to the things that are being enumerated (enum cases) seems more purposeful. > Brent just wrote that he might later propose to extend `ValueEnumerable` to > `Bool` and `Optional`, To be fair, Optional *is* an enum, and Bool really should be (we only switched it to its current design for internal optimizer reasons). Making Bool conform to this would require manual conformance - if we were motivated to give Bool all the enum-like facilities (including a Bool.true and Bool.false member) then having it conform seems conceptually fine to me. I would personally object to attempts to make optional conform though. One of its cases has an associated value and this isn’t something we should support IMO. I believe that this is one of the roots of your objection. -Chris _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
