<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Zef, do you really think `rawValues` are worth adding?</div><div class=""><br class=""></div><div class="">With `cases`, they would be one `map` away, no?</div><div class=""><br class=""></div><div class="">R+</div><br class=""><div><blockquote type="cite" class=""><div class="">On 23 Dec 2015, at 17:21, Zef Houssney via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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; -webkit-line-break: after-white-space;" class=""><div class="">To be clear, I think there should be a distinction between what would be returned by `cases` and `rawValues`, and I think there is good reason to include both:</div><div class=""><br class=""></div><div class="">- `cases` would return actual instances of the enum type, or the constructor if there is an associated value for the case and an instance can’t be automatically created</div><div class="">- `rawValues` would also exist for enums that have a RawRepresentable value.</div><div class=""><br class=""></div><div class="">The collision of using “case" in something like `for case in SomeEnum.cases` is unfortunate, but I think it’s still the most clear and accurate representation of something that does what I described above. Initially I was thinking there was an existing proposal that would fix this, but now I realize that it’s only scoped to keyword arguments: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0001-keywords-as-argument-labels.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0001-keywords-as-argument-labels.md</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Joe, thank you for your thoughts on this! Yes I agree that it doesn’t make sense to try to generate a list of all possible values for all associated types — and that’s pretty much my point. Deciding to omit such unsupported cases is one way to deal with that issue, but it seems confusing and limiting to me that some enum cases would not be represented in the array of values, while others are represented multiple times. I’m not saying that there’s no value to something like that and I’m certainly not opposed to the inclusion of that kind of thing, but I’m interested in finding a way to deal with this in a manner that is more understandable, predictable, and flexible.<div class=""><div class=""><br class=""></div><div class="">I’d love to hear what you think about returning an array that includes constructors for the cases with associated values. Here’s what I like about that idea:</div><div class=""><br class=""></div><div class="">- The array consists of a 1-to-1 mapping regardless of the type of case. This is more understandable and predictable in my opinion.</div><div class="">- It provides the ability to cover more use-cases, while I believe the other approach would prevent certain things from being possible in a dynamic way.</div><div class="">- It still allows for developers to generate an array with the recursive structure/Cartesian product as you described.</div><div class=""><br class=""></div><div class=""><div class="">Here is an example that demonstrates the usefulness of constructors as the included value for cases with associated values. I am providing a stubbed implementation of a `cases` static var. The concept is that you have an enum that defines a number of built-in color schemes, but provides a mechanism for users to dynamically create their own color schemes.</div><div class=""><br class=""></div><div class=""><a href="https://gist.github.com/zef/c6069ed4ed11e41661bf" class="">https://gist.github.com/zef/c6069ed4ed11e41661bf</a></div><div class=""><br class=""></div><div class="">I have a couple other real-world ideas for where this would be useful too.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">Downsides I can see to this approach:</div><div class=""><br class=""></div><div class="">- For enums that have disparate constructor signatures, [Any] would have to be the return value of cases, which doesn’t seem ideal because the cases array would always require some kind of manual manipulation to be useful.</div><div class="">- There isn’t currently a way in the type system to know what case you are working based on the constructor. For instance say two cases both have a constructor of (String), you can’t determine which case you are working on until you call the constructor to instantiate the case. This could be done by looking at the index of the constructor in the cases array, but that is brittle and messy. If there was a way to determine that more dynamically, this would be more powerful and easier to use.</div></div><div class=""><div class=""><br class=""></div></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 23, 2015, at 6:00 AM, Pierre Monod-Broca via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">+1 for an ordered collection of all cases, it could be an ordered set to please proponents of a set.<div class=""><br class=""></div><div class="">I have no strong opinions about the name</div><div class="">`cases` is good, but I agree it begs to do ''for case in SomeEnum.cases''</div><div class="">`values` is good, and IMO it's consistent with `rawValue` when there is one, not confusing<br class=""><div class=""><br class=""></div><div class=""><div class="">
<div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">--&nbsp;</div><div class="">Pierre</div></div>
</div>
<br class=""></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=vC-2FQIU-2BCsLz-2Fl3B9m6u7iK-2B0lKodY1r4omFmZD8Y0qYEb3jW7rprY7EClv7eqg0jy8SYRGl77S8e7GI9DjNEY4c5QtzY4YEyZEaJKimq5pT5Reg-2Fx4iI7pFcwm84XUXvmAa4yHBYH7njbghvbXt4a6VTbyUA7tzBn6kU2BYviO7TZPP5WVMIrdo9qvb2ftt7riGJfSocelbZ4cgHRqd-2FRBJwSgyscyZ26QfCPe0jZpg-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class="">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=j4IybsUIPYHiRcwUyRdFaVaGfC-2BcuSF87gNiFbXXBmTC4RtFUsbn26JbeohWEYOHQ1swcHoSf2hqFrRIzHRhrFCvwQiTTTcB22b6vbR-2FGubvs7pt9ANSUyjqJq2G1KVgvQ8ON00V940MpM3d72ZegDz7LuwjQAGBY8YrZR7iG9-2BG9xdL488smzsGDOpiRpC5pLIu-2FZ1r6zGM1-2BYa0TONwA-3D-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</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=""></body></html>