<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">A strong +1 on this approach instead of the current revision of SE-0194.</div><div class=""><br class=""></div>This is a very focused solution to a very focused need. It sidesteps the issues of a protocol based approach (potential for abuse or deciding/defining the intended uses of such protocol). Also, we already have the underpinnings of such literals, which makes it straightforward to implement. <div class=""><br class=""></div><div class="">If we decide to do anything other than this, it will need a pretty strong argument.<div class=""><br class=""></div><div class="">This is also the least disrupting solution as it is basically what we are manually doing right now: We declare a static property that is nothing more than an array literal that captures cases that exist at the time of compilation in the source code order. We can just replace the manually written array literal with this one and be sure it will stay in sync, which minimizes overhead of transition for existing code and does not impose any particular style or arise the questions about the data type of this “collection”. (We can use any type that is `ExpressibleByArrayLiteral`)</div><div class=""><br class=""></div><div class="">We could also have a variant of this literal that would also capture the related metadata. For example, each element of the literal array could be tuples of each case value and another literal (an enum case maybe) that represents the availability metadata for that case.</div><div class=""><br class=""></div><div class="">Hooman</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 14, 2018, at 8:16 AM, Ben Rimmington via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">An alternative is a special #knownCases(of:) literal.</div><div class=""><br class=""></div><div class="">Its value is an array literal of the enum cases known at compile time.</div><div class=""><br class=""></div><div class="">This could also work with enums imported from Objective-C.</div><div class=""><br class=""></div><div class="">-- Ben</div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 10 Jan 2018, at 22:54, Jordan Rose wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md</a>]</div><div class=""><br class=""></div><div class="">I think this is generally reasonable, and none of the names offend me enough to weigh in on that discussion. I do think it's a little weird that @objc enums defined in Swift <i class="">cannot</i> conform to ValueEnumerable, just because imported enums won't. (But especially while knee-deep in SE-0192, I think it's <i class="">correct</i> that imported enums won't. The exception could be C enums marked `enum_extensibility(closed)`, but I'm not convinced we need that yet.)</div><div class=""><br class=""></div><div class="">The biggest problem I have is unavailable cases. An unavailable case <i class="">must not</i> be instantiated—consider an enum where some cases are only available on iOS and not macOS. (I bet we optimize based on this, which makes it all the more important to get right.)</div><div class=""><br class=""></div><div class="">I think you should explicitly call out that the derived implementation only kicks in when ValueEnumerable is declared on the enum itself, not an extension. Or if that's not the case, it should be limited to extensions in the same module as the enum. (You could add "unless the enum is '@frozen'", but that's not really necessary.)</div><div class=""><br class=""></div><div class="">I don't think this should be implemented with a run-time function; compile-time code generation makes more sense to me. But that's an implementation detail; it doesn't change the language surface.</div><div class=""><br class=""></div><div class="">Jordan</div></div></div></blockquote></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>