<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 9, 2017 at 11:36 AM Matthew Johnson 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 dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Sep 9, 2017, at 11:42 AM, gs. <<a href="mailto:griotspeak@gmail.com" target="_blank">griotspeak@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div>How does fragility play into this? Does this only work for fragile (closed) and internal/private/fileprivate enums?<br></div></div></blockquote><div><br></div><div>That's a great question. I think it would have to have that limitation. Using Jordan's terminology, by definition a nonexhaustive cannot provide a complete list of all values.</div></div></blockquote><div><br></div><div>This one is tougher for me to make a call. I definitely see the point of view that says that if a nonexhaustive enum doesn't provide a complete list, then it would make sense to not synthesize it. On the other hand, some nonexhaustive enums may still benefit from that. For example, I've been tinkering with wrapping the ICU APIs in Swift, and I have an <a href="https://github.com/allevato/icu-swift/blob/master/Sources/ICU/Block.swift">enum for Unicode code blocks</a>. That would be a good candidate for a nonexhaustive enum because the spec is always growing, but it would still be very useful to have the compiler synthesize the collection and count for me (for example, to display in a table), especially since it is large.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br><blockquote type="cite"><div><div><br>TJ </div></div></blockquote></div><div dir="auto"><blockquote type="cite"><div><div><br>On Sep 9, 2017, at 15:23, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div><br><br>Sent from my iPad</div><div><br>On Sep 9, 2017, at 7:33 AM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div><blockquote type="cite"><div>On Sep 8, 2017, at 5:14 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_2402340347077709970Apple-interchange-newline"><div><span 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;float:none;display:inline!important">Here, people just want an array of all cases. Give them an array of all cases. When it's not possible (i.e., in the case of cases with associated values), don't do it.</span></div></blockquote></div><div><br></div><div>I agree it should be Int-indexed; that seems to be what people want from this.</div><div><br></div><div>I seem to recall that there is information about the available enum cases in the module metadata. If so, and if we're willing to lock that in as part of the ABI design, I think we should write—or at least allow for—a custom Int-indexed collection, because this may allow us to recurse into associated value types. If we aren't going to have suitable metadata, though, I agree we should just use an Array. There are pathological cases where instantiating a large Array might be burdensome, but sometimes you just have to ignore the pathological cases.</div><div><br></div><div>(The "infinite recursion" problem with associated values is actually relatively easy to solve, by the way: Don't allow, or at least don't generate, `ValuesEnumerable` conformance on enums with `indirect` cases.)</div></div></blockquote><div><br></div><div>This is the direction I think makes the most sense in terms of how we should approach synthesis. The open question in my mind is what the exact requirement of the protocol should be. Should it exactly match what we synthesize (`[Self]` or an associated `Collection where Iterator.Element == Self, Index == Int`) or whether the protocol should have a more relaxed requirement of `Sequence where Iterator.Element == Self` like Tony proposed.</div><br><blockquote type="cite"><div><br><div>
<span class="m_2402340347077709970Apple-style-span" style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div style="font-size:12px">-- </div><div style="font-size:12px">Brent Royal-Gordon</div><div style="font-size:12px">Architechies</div></div></span>
</div>
<br></div></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote></div>_______________________________________________<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>