<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 HasOnlyAFixedSetOfPossibleValues {</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: HasOnlyAFixedSetOfPossibleValues {</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 HasOnlyAFixedSetOfPossibleValues, 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 dir="ltr">On Mon, Mar 13, 2017 at 4:43 PM David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Mar 10, 2017, at 10:15 AM, Trevör ANNE DENISE via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-8660283315611481394Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg">Hello everyone,<div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_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="gmail_msg">This is similar to what has been described there:</div><div class="gmail_msg"><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001233.html" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001233.html</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Is there any updates about it since 2015?</div></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Also, do you think this would be a good idea to make extensions constrainable by enum types, like that?</div><div class="gmail_msg">extension Type where P1: enum {</div><div class="gmail_msg">}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">You could then write something similar to this:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">protocol A {</div><div class="gmail_msg">associatedtype P1</div><div class="gmail_msg">associatedtype P2</div><div class="gmail_msg">static var p1PossibleValues:[P1] { get }</div><div class="gmail_msg">static var p2PossibleValues:[P2] { get }</div><div class="gmail_msg">}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">extension A where P1: enum, P2: enum {</div><div class="gmail_msg"><span class="m_-8660283315611481394Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>static var p1PossibleValues:[P1] { return p1PossibleValues.allValues }</div><div class="gmail_msg"><span class="m_-8660283315611481394Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>static var p2PossibleValues:[P2] { return p2PossibleValues.allValues }</div><div class="gmail_msg">}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Would it make sense to do it this way?</div></div></div></blockquote><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_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="gmail_msg" target="_blank">https://github.com/TheOtherDave/EnumEnhancer</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Hope that helps</div><div class="gmail_msg">- Dave Sweeris</div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>