<div dir="ltr">See: <a href="https://github.com/apple/swift-evolution/pull/114">https://github.com/apple/swift-evolution/pull/114</a><div>According to that discussion, the core team has decided that this is out of scope for Swift 4 stage 2.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 13, 2017 at 7:44 PM, Tony Allevato via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think having a static collection of enum values for enums where no cases have associated values is a totally reasonable thing to do, and I think omitting this on enums with associated values is also completely reasonable. In a sense, those two kinds of enums serve different purposes: the former usually describe a finite set of discrete *fixed* values, where a collection of them makes sense; the latter is more often an infinite (theoretically) or at least finite and large collection of *parameterized* values where a preëxisting set can't or shouldn't be known.<div><br></div><div>Rather than constrain against "enum", which I think would be problematic because of those differences among enums, I think a good way to do this would be to model it with a protocol and have the compiler synthesize it when possible. For example, imagine this protocol, which I'll give a really terrible and contrived name because I can't think of a good one currently:</div><div><br></div><div>```</div><div>protocol HasOnlyAFixedSetOfPossibleValu<wbr>es {</div><div> static var allValues: [Self] { get }</div><div>}</div><div>```</div><div><br></div><div>then the compiler could synthesize it such that the given definition:</div><div><br></div><div>```enum Foo { case bar, baz, quux }```</div><div><br></div><div>actually becomes</div><div><br></div><div>```</div><div>enum Foo: <wbr>HasOnlyAFixedSetOfPossibleValu<wbr>es {</div><div> case bar, baz, quux</div><div> static var allValues: [Foo] { return [.bar, .baz, .quux] }</div><div>}</div><div>```</div><div><br></div><div>Then, you can get the behavior you want by constraining against HasOnlyAFixedSetOfPossibleValu<wbr>es, which is more in line with how you would use similar protocols like RawRepresentable. It also means you could have non-enum types conform to it and use them in the same contexts, if it made sense to do so.</div><div><br></div><div>Of course, there are a bunch more questions to be addressed, like what type allValues should be, should it be lazy, should it be ordered, etc., but making it protocol-driven feels like it would best fit in the language. The basic building blocks are already there; you just need to define the protocol and have the compiler generate its implementation like the others that it already does.</div><div><br></div></div><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Mon, Mar 13, 2017 at 4:43 PM David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="word-wrap:break-word" class="m_4504509576935306875gmail_msg"><br class="m_4504509576935306875gmail_msg"><div class="m_4504509576935306875gmail_msg"><blockquote type="cite" class="m_4504509576935306875gmail_msg"><div class="m_4504509576935306875gmail_msg">On Mar 10, 2017, at 10:15 AM, Trevör ANNE DENISE via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_4504509576935306875gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_4504509576935306875m_-8660283315611481394Apple-interchange-newline m_4504509576935306875gmail_msg"><div class="m_4504509576935306875gmail_msg"><div style="word-wrap:break-word" class="m_4504509576935306875gmail_msg">Hello everyone,<div class="m_4504509576935306875gmail_msg"><div class="m_4504509576935306875gmail_msg"><br class="m_4504509576935306875gmail_msg"></div><div class="m_4504509576935306875gmail_msg">As I was writing a program, I realised that I could make it safer by being able to list all possible cases of a Swift enum.</div><div class="m_4504509576935306875gmail_msg">This is similar to what has been described there:</div><div class="m_4504509576935306875gmail_msg"><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001233.html" class="m_4504509576935306875gmail_msg" target="_blank">https://lists.swift.org/<wbr>pipermail/swift-evolution/<wbr>Week-of-Mon-20151207/001233.<wbr>html</a></div><div class="m_4504509576935306875gmail_msg"><br class="m_4504509576935306875gmail_msg"></div><div class="m_4504509576935306875gmail_msg">Is there any updates about it since 2015?</div></div><div class="m_4504509576935306875gmail_msg"><br class="m_4504509576935306875gmail_msg"></div><div class="m_4504509576935306875gmail_msg">Also, do you think this would be a good idea to make extensions constrainable by enum types, like that?</div><div class="m_4504509576935306875gmail_msg">extension Type where P1: enum {</div><div class="m_4504509576935306875gmail_msg">}</div><div class="m_4504509576935306875gmail_msg"><br class="m_4504509576935306875gmail_msg"></div><div class="m_4504509576935306875gmail_msg">You could then write something similar to this:</div><div class="m_4504509576935306875gmail_msg"><br class="m_4504509576935306875gmail_msg"></div><div class="m_4504509576935306875gmail_msg">protocol A {</div><div class="m_4504509576935306875gmail_msg">associatedtype P1</div><div class="m_4504509576935306875gmail_msg">associatedtype P2</div><div class="m_4504509576935306875gmail_msg">static var p1PossibleValues:[P1] { get }</div><div class="m_4504509576935306875gmail_msg">static var p2PossibleValues:[P2] { get }</div><div class="m_4504509576935306875gmail_msg">}</div><div class="m_4504509576935306875gmail_msg"><br class="m_4504509576935306875gmail_msg"></div><div class="m_4504509576935306875gmail_msg">extension A where P1: enum, P2: enum {</div><div class="m_4504509576935306875gmail_msg"><span class="m_4504509576935306875m_-8660283315611481394Apple-tab-span m_4504509576935306875gmail_msg" style="white-space:pre-wrap"> </span>static var p1PossibleValues:[P1] { return p1PossibleValues.allValues }</div><div class="m_4504509576935306875gmail_msg"><span class="m_4504509576935306875m_-8660283315611481394Apple-tab-span m_4504509576935306875gmail_msg" style="white-space:pre-wrap"> </span>static var p2PossibleValues:[P2] { return p2PossibleValues.allValues }</div><div class="m_4504509576935306875gmail_msg">}</div><div class="m_4504509576935306875gmail_msg"><br class="m_4504509576935306875gmail_msg"></div><div class="m_4504509576935306875gmail_msg">Would it make sense to do it this way?</div></div></div></blockquote><br class="m_4504509576935306875gmail_msg"></div></div><div style="word-wrap:break-word" class="m_4504509576935306875gmail_msg"><div class="m_4504509576935306875gmail_msg">Almost… You could have the compiler generate that for 2/3 of the types of enum, but it can’t do anything with enums that have associated values. I wrote a bit of software a while back that does as much as I could figure out how to do automatically, then makes in a compile-time error to not fill-in the blanks (which is still annoying, but at least you don’t find out about your mistake when your program crashes). Feel free to do whatever you want with it: <a href="https://github.com/TheOtherDave/EnumEnhancer" class="m_4504509576935306875gmail_msg" target="_blank">https://github.com/<wbr>TheOtherDave/EnumEnhancer</a></div><div class="m_4504509576935306875gmail_msg"><br class="m_4504509576935306875gmail_msg"></div><div class="m_4504509576935306875gmail_msg">Hope that helps</div><div class="m_4504509576935306875gmail_msg">- Dave Sweeris</div></div></div></div>______________________________<wbr>_________________<br class="m_4504509576935306875gmail_msg">
swift-evolution mailing list<br class="m_4504509576935306875gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="m_4504509576935306875gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_4504509576935306875gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_4504509576935306875gmail_msg" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br class="m_4504509576935306875gmail_msg">
</blockquote></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>