<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 11, 2017, at 5:11 AM, Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><span 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-stroke-width: 0px; float: none; display: inline !important;" class="">Closed would not be an access level, just an attribute orthogonal to the others.</span></div></blockquote><div>As Xiaodi pointed out, there's still no agreement on that — so basically I'm saying that I prefer your interpretation, because imho five access levels are already a alarmingly high number.</div></div></div></blockquote><div><br></div>Well we're going to have a concept of closed enum regardless of how we spell it syntactically. I don't think making it an access level adds any complexity over using an attribute. I think it reduces complexity by making the language more consistent.<div><br><blockquote type="cite"><div><div><br class=""><blockquote type="cite" class=""><div class=""><span 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-stroke-width: 0px; float: none; display: inline !important;" class="">What do you mean by the six different flavors?</span></div></blockquote></div>1) cases with associated objects<div class="">2) raw-based enums</div><div class="">3) everything else (not that much different from int-based)</div><div class=""><br class=""></div><div class="">With the new attribute, there would be a new variant for each type, therefor six flavours (I choose this term because it's only small variation — but still, it might look quite complex to someone coming from C or Java).</div><div class=""><br class=""></div><div class="">The major issue I have with this change is how it will work in real live:</div><div class="">When I write a library and declare that I'll never add new cases to an enum, who will enforce this?</div><div class="">Will the compiler interact with git and look for release tags, or will there be a lockdown-command that records all cases and compares them with the last time the command was triggered?</div><div class="">This feels really brittle to me, and I haven't seen a approach that would be fundamental different (and better).</div></div></blockquote><div><br></div><div><span style="background-color: rgba(255, 255, 255, 0);">We are not talking about *adding* closed enums to the language. </span>They already exist and will continue to exist. We're just talking about how to spell them in the future when we also have resilient enums (i.e. allowing a library to add new cases in a future version without breaking compatibility). <span style="background-color: rgba(255, 255, 255, 0);">I don't have a complete answer here about the details, but there is a plan to provide tool support to help with library evolution and detecting breaking changes. </span></div><br><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></div></body></html>