<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Feb 10, 2017, at 9:22 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Fri, Feb 10, 2017 at 7:23 PM, Slava Pestov via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Feb 10, 2017, at 8:55 AM, Tino Heth <<a href="mailto:2th@gmx.de" target="_blank">2th@gmx.de</a>> wrote:</div><br class="m_2276264861830285121m_7050361318357395191Apple-interchange-newline"><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><blockquote type="cite" 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"><div><div style="word-wrap:break-word"><div>I'm not sure if I like the concept of having two kinds of enum.</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"><br></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">Why not? Bool-like enums would be declared ‘closed’, and would not require a default case (but adding a new case would then break ABI).</span></div></div></div></blockquote><div><br></div><div>Well, enums are already (relative) complex, and with this addition, there would be six different flavors.</div><div>Imho it would be less bad if we could recycle existing modifiers, but with a hypothetic "closed" access level added as well, I have strong doubts that the feature carries its weight.</div></div></div></div></blockquote><div><br></div></span>Closed would not be an access level, just an attribute orthogonal to the others. What do you mean by the six different flavors?</div></div></blockquote><div><br></div><div>My read of Matthew Johnson's pitch is that `closed` is to be a sixth access level.</div></div></div></div></div></blockquote><div><br></div><div>This is correct. It isn't immediately obvious, but when you step back and consider things from a high level point of view it seems to fall pretty naturally out of the logic we used when we made `open` and access level. </div><div><br></div><div>Closed is talking about the same thing `open` is: who is allowed to add to the set of cases, subclasses or protocols of an enum, class, or protocol. It just moves in the opposite direction from `public` than `open` does. Once you realize this, any other spelling of `closed` would make the language feel inconsistent IMO. If `open` works as an access level `closed` should also.</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div>For better or worse we need the ability to define enums that admit new cases without breaking ABI. Whether or not this is the default for all enums, or enabled with a special attribute can be designed later when we send out evolution proposals for resilience-related features.</div></div></div></blockquote>Intuitively, I thought this should not affect ABI… but no matter what instability this is, I guess it could definitely crash an application that is confronted with an unexpected case ;-)</div><div><br></div><div>Wouldn't it be possible to create an implicit default case for every switch-statement?</div></div></div></blockquote></div><br></span></div><br>______________________________<wbr>_________________<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/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></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></body></html>