<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>The “base” case desire makes sense to me, but not as a part of this proposal. It might be a good follow-on. </div><div><br></div><div>If all associated values are enumerable, it is tempting to try to make the top level enum valueEnumerable too. I wonder if even that should be a follow-on feature. </div><div><br></div><div>As far as source-order, I want something like fragile enums to serve double-duty - but given where that discussion has gone I am not sure that is a possibility any more.</div><div><br></div><div>My planned next step is to write up some of these usage desires and constraints, and contribute those to the proposal. </div><div><br></div><div>If we can coalesce towards something (magic for loop, collection property...) I would like to investigate implementation and see how feasible it is for me. I don’t know expect to be particularly quick at it but hopefully I can help move things along. </div><div><br>On Dec 9, 2017, at 9:27 PM, Jonathan Hull via swift-evolution via swift-dev <<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 14, 2017, at 9:06 PM, Brent Royal-Gordon via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class="">On Nov 14, 2017, at 5:21 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="gmail_extra"><div class="gmail_quote"><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 class="" style="word-wrap: break-word;"><div class="">1. It must be possible to easily access the count of values, and to access any particular value using contiguous `Int` indices. This could be achieved either by directly accessing elements in the list of values through an Int subscript, or by constructing an Array from the list of values.</div><div class=""><br class=""></div><div class="">2. It must be possible to control the order of values in the list of values, either by using source order or through some other simple, straightforward mechanism..</div></div></blockquote><div class=""> </div><div class="">OK, first of all, nowhere in the proposal text are these requirements stated as part of the use case. You're free to put forward new use cases, but here I am trying to design the most elegant way to fulfill a stated need and you're telling me that it's something other than what's written.</div></div></div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Honestly, re-reading the proposal, it never cites a fully-formed use case. Instead, it cites several blog posts, Stack Overflow questions, and small code samples without digging in to the underlying reasons why developers are doing what they're doing. Most of the people discussing it so far seem to have had a tacit understanding that we wanted roughly Array-like access, but we haven't explicitly dug into which properties of an Array are important.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">(If anyone involved feels like they had a different understanding of the use case, please speak up.)</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I think this is a place where the proposal can be improved, and I'm willing to do some writing to improve it.</div></div></div></div></blockquote></div><div class=""><br class=""></div><div class="">This is a feature I have been requesting since Swift 1. If the resulting ordering is not SOURCE ordering, this feature loses most of it’s usefulness for me. I would say around 80% of my uses for this require a predictable ordering (and I don’t consider something based on compiler internals predictable) which I can control. As Brent said, most of those cases involve something that shows to the user in some way. The weekday example was a good one (I actually have that in my code). </div><div class=""><br class=""></div><div class="">The most painful case of this being missing was where I needed an enum of all country codes (it is a beast to maintain). In that case, I am displaying them to the user in a tableView (along with icons named by the country codes), but I am also filtering them based on the user’s input in a search field. To do both, you need to be able to iterate/filter an array of cases. Awful to build. Just awful.</div><div class=""><br class=""></div><div class="">Also, I would greatly prefer an allValues/allCases method to having the type be a collection. It just reads clearer in code what is going on. I think what I basically want to see is:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol ValueEnumerable {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var allValues:Collection<Self></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><br class=""></div><div class="">…where both the conformance and implementation are automatically inferred for enums when possible.</div><div class=""><br class=""></div><div class="">I would probably also end up using this protocol on Structs that I use as extensible enums. That is, I have a private/internal initializer and use static vars in place of the cases. This isn’t perfect, since part of the reason I use these structs is that they can be built in a distributed way… but I could find a way to build that array in a mostly distributed way as well (and if we ever get the Multi-function capability I have suggested elsewhere, then it could be truly distributed).</div><div class=""><br class=""></div><div class="">Semantically, the protocol should infer not only a finite number of cases, but a number that can be iterated over in a reasonable period of time.. I would be fine with Bool conforming, but not with Int. With those semantics, I could easily see a follow-on proposal which says that associated cases where all of the values are ValueEnumerable are ValueEnumerable themselves. This would be super useful for cascading enums. I have a game that I am working on in my spare time right now, where effects of actions are represented as enums, with a single enum for all effects that references more specific enums for each type of thing that can be affected.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">One other common need which I feel I should bring up even though it is a bit tangential, is that when I have enums with associated values, 90% of the time, I end up wanting a way to refer to the base of that without the value. For example, if the player has a case called ‘damage’ which has an associated Int, I end up wanting to ask (and sometimes store) if the case is a ‘damage’ case. Often, I am trying to match against patterns: Were there two damages followed by a block? What I end up doing is creating a second enum with the same cases (sans values) and then creating a mapping between the two. Busywork in the same way writing these allValues arrays are busywork. If we end up creating a way to reference just the base, maybe the allValues array should just contain those bases for non-enumerable associated values. Food for thought.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div><div class=""><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-dev mailing list</span><br><span><a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-dev">https://lists.swift.org/mailman/listinfo/swift-dev</a></span><br></div></blockquote></body></html>