<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 22, 2016 at 10:50 PM, John McCall <span dir="ltr">&lt;<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><div><div><br></div></div></div></div>I have not been following this discussion, but I would be extremely antsy about guaranteeing any particular representation for the set of values.  Guaranteeing a contiguous array implementation seems like a really bad idea, especially if that&#39;s taken to mean that we&#39;re going to actually provide a static global array.  But there&#39;s no way to avoid providing a public API, because a public conformance itself implies a public API with some level of corresponding overhead.</div></blockquote><div><br></div><div>A &quot;compiler magic&quot; version of the feature, like #allValues(MyEnum), could generate a static array *internal* to the caller&#39;s module, but I&#39;m sure there are implications or details of this which I&#39;m not aware of.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>I don&#39;t remember the details of Java enums from my days as a Java programmer, but reading between the lines of your description, it sounds to me like Java originally made overly-strong guarantees that it decided to walk back in a later release.  That&#39;s a lesson we should heed.</div></div></blockquote><div><br></div><div>Maybe I missed something, but that&#39;s not how I interpreted it. The guarantee was/is simply that getEnumConstants() returns the values in source order. If the class being loaded changes (excuse my Java ignorance if that&#39;s the wrong terminology), you may end up with different results at runtime, but it&#39;s still an array of the values in the order they&#39;re defined in the class. Of course, Java enums seem to be much simpler (they can have payloads/members, but the values are fixed for the cases you define at compile-time).</div><div><br></div><div>I just noticed there&#39;s a MyEnum.values() method too, but it seems to do the same thing as getEnumConstants(). &lt;<a href="http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html">http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html</a>&gt;</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>The interaction of resilience with enums is in principle quite straightforward: you ought to be able to arbitrarily change the set of stored cases for a resilient enum.  That includes adding cases, changing existing cases to be &quot;computed&quot;, and so on.  (We haven&#39;t yet designed what it ought to mean for a case to be computed, but I assume it at least means providing an injector (Payload -&gt; Enum) and a projector (Enum -&gt; Payload?); whether and how to allow computed cases to factor into exhaustiveness checking is a separate but crucial question.)  The fundamental problem for features like this is that adding a case with a payload is not compatible with actually being enumerable, outside of special cases and/or some formal-but-useless notion of recursive enumerability.  But even if you couldn&#39;t add new cases with payloads (which is something we might consider adding as an intermediate opt-in constraint), and thus the type was necessarily finite, I can&#39;t imagine wanting to promise to return a static global array.</div></div></blockquote></div><br></div><div class="gmail_extra">Non-&quot;simple&quot; enums (those with cases with payloads, generic enums, etc.) are out of scope for this proposal. There are multiple ways in which you might want them to be &quot;enumerable&quot;, and anyway, it seems like a job for better reflection. There&#39;s some discussion in the &quot;Future directions&quot; section at the bottom (which I&#39;ll probably remove): &lt;<a href="https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md">https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md</a>&gt;  For now we&#39;d like to start with something simple but functional.</div></div>