<div dir="ltr">I read:<br><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;word-wrap:normal;padding:16px;overflow:auto;line-height:1.45;background-color:rgb(246,248,250);border-radius:3px;word-break:normal;color:rgb(36,41,46)">Ma.<span class="inbox-inbox-pl-smi" style="box-sizing:border-box">allValues</span>.<span class="inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">count</span> <span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="inbox-inbox-pl-c" style="box-sizing:border-box">//</span> returns 8</span></pre><div>But that sounds like all values will need to be computed in order to get the count, so some people will be tempted to write:</div><div><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;word-wrap:normal;padding:16px;overflow:auto;line-height:1.45;background-color:rgb(246,248,250);border-radius:3px;word-break:normal;color:rgb(36,41,46)">Ma.lazy.<span class="inbox-inbox-pl-smi" style="box-sizing:border-box">allValues</span>.<span class="inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">count</span> <span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="inbox-inbox-pl-c" style="box-sizing:border-box">//</span> returns 8</span></pre></div><div>To avoid that, it may be nicer to make enum `Ma` behaves like a collection directly, so that we can write:</div><div><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;word-wrap:normal;padding:16px;overflow:auto;line-height:1.45;background-color:rgb(246,248,250);border-radius:3px;word-break:normal;color:rgb(36,41,46)">Ma.<span class="inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">count</span> <span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="inbox-inbox-pl-c" style="box-sizing:border-box">//</span> returns 8
Ma.<span class="inbox-inbox-inbox-inbox-pl-c1" style="font-size:13.6px;box-sizing:border-box;color:rgb(0,92,197)">map</span> { return "\($0)" } // returns a stringification</span></pre></div>A little bit like what was done on String when we dropped the requirement of writing `.characters`, it would be perfect to directly drop the requirement of writing `.allValues`.<div><br><div class="gmail_quote"><div dir="ltr">Le mer. 10 janv. 2018 à 14:40, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
> My objection to the "ValueEnumerable" design--especially in its generalized form here (versus "CaseEnumerable")--is that the protocol's semantics (and, we'll recall, protocols in Swift must offer semantics that make possible useful generic algorithms) are so broad as to be little more than essentially what it means to be a type.<br>
<br>
Thank you for writing this up Xiaodi. I completely agree with you that “CaseEnumerable” is a better name for this: it is more specific and purposeful and make it more clear what the purpose and scope is.<br>
<br>
Your later suggestion of “Enumerable” seems to broad and potentially confusing to me. Tying it to the things that are being enumerated (enum cases) seems more purposeful.<br>
<br>
<br>
> Brent just wrote that he might later propose to extend `ValueEnumerable` to `Bool` and `Optional`,<br>
<br>
To be fair, Optional *is* an enum, and Bool really should be (we only switched it to its current design for internal optimizer reasons).<br>
<br>
Making Bool conform to this would require manual conformance - if we were motivated to give Bool all the enum-like facilities (including a Bool.true and Bool.false member) then having it conform seems conceptually fine to me.<br>
<br>
I would personally object to attempts to make optional conform though. One of its cases has an associated value and this isn’t something we should support IMO. I believe that this is one of the roots of your objection.<br>
<br>
-Chris<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div>