<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 10, 2017, at 3:52 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica, Arial; font-size: 13px; 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;" class=""><br class="Apple-interchange-newline"><br class="">On 10 Aug 2017, at 22:36, Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com" class="">adrian.zubarev@devandartist.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica, Arial; font-size: 13px; 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><div class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">Okay I came to the conclusion that this won’t work that easily. Here is my reasoning why I think that way. If one assume for a second that one day we might have value sub typing - yes not now and not in the next Swift version, but hear me out please - we will come back and discuss the alignment of `open/public` for value types (including enums of course)</div></div></blockquote><div style="font-family: Helvetica, Arial; font-size: 13px; 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;" class=""><br class=""></div><div style="font-family: Helvetica, Arial; font-size: 13px; 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;" class="">Does value sub-typing really imply overriding? Because if that’s not the case, we won’t need the open keyword to limit overriding.</div></div></blockquote><div><br class=""></div>It definitely does not in my opinion. Value sub typing is effectively a form of implicit conversion that is guaranteed to succeed in producing a value of a different type (typically with a large set of inhabitants) that is logically equivalent.</div><div><br class=""><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica, Arial; font-size: 13px; 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;" class=""><blockquote type="cite" style="font-family: Helvetica, Arial; font-size: 13px; 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><div class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">which would allow us to create sub/super Types of an enum from module A in module B with `open` modifier, where on the other hand `public` would restrict sub/supertyping to the module where the enum is defined, very similar to classes. Here is the tricky part now. If we’d add a `closed` modifier which implies `public` then we end up with a hole that cannot be filled at that point of time, because we would only be able to declare a public-but-open and a public-but-closed enum. However we still would need be able to create an open-but-open enum (lhs open is the constraints for sub typing, rhs open is the constraint that we talk about in this thread). Therefore to support open-but-open version we would require a special keyword.</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">I want to modify your main idea into:</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">(Potentially possible in the future)</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">- open-but-finite enum - or simply: open finite enum</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">- open-but-infinite enum - or simply: open enum</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">(Version that we could make possible in Swift 5)</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">- public-but-finite enum - or simply: public finite enum</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">- public-but-infinite enum - or simply: public enum</div><br class=""><div id="bloop_sign_1502396328534311168" class="bloop_sign"></div><br class=""><p class="airmail_on">Am 10. August 2017 um 22:00:40, David Hart (<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>) schrieb:</p><blockquote type="cite" class="clean_bq"><span class=""><div dir="auto" class=""><div class=""></div><div class=""><br class=""><div class=""><br class="">On 10 Aug 2017, at 19:19, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Aug 9, 2017, at 22:46, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 10 Aug 2017, at 02:42, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class="">:-) As you've all noted, there are some conflicting concerns for the default:</div><div class=""><br class=""></div><div class="">- Source compatibility: the existing behavior for an unannotated enum is "closed".</div><div class="">- Intuition: if you show someone an enum without an explicit annotation, they'll probably expect they can switch over it. (I'm going to say this is why Zach calls it a "sensible default".)</div><div class="">- Consistency: switches on an enum in the same module can always be exhaustive, so having it be different across modules is a bit annoying. (But 'public' already acts like this.)</div><div class=""><br class=""></div><div class="">vs.</div><div class=""><br class=""></div><div class="">- Library evolution: the default should promise less, so that you have the opportunity to change it.</div><div class="">- Flexibility: you can emulate an exhaustive switch with a non-exhaustive switch using fatalError, but not the other way around.</div><div class=""><br class=""></div><div class="">All of this is why I suggested it be an explicit annotation in either direction, but Matthew brought up the "keyword soup" problem—if you have to write (say) "public finite enum" and "public infinite enum", but would never write "private finite enum" or "private infinite enum",<span class="Apple-converted-space"> </span><i class="">something</i> is redundant here. Still, I'm uncomfortable with the default case being the one that constrains library authors, so at<span class="Apple-converted-space"> </span><i class="">least</i> for binary frameworks (those compiled "with resilience") I would want that to be explicit. That brings us to one more concern: how different should binary frameworks be from source frameworks?</div></div></div></blockquote><div class=""><br class=""></div><div class="">In terms of intuition and consistency, I think we should really try to learn from the simplicity of public/open:</div><div class=""><br class=""></div><div class="">* When<span class="Apple-converted-space"> </span><b class="">internal</b>, classes are sub-classable by default for<span class="Apple-converted-space"> </span><b class="">convenience</b>, but can be closed with the<span class="Apple-converted-space"> </span><b class="">final</b><span class="Apple-converted-space"> </span>keyword</div><div class="">* When<span class="Apple-converted-space"> </span><b class="">public</b>, classes are closed to sub-classing for<span class="Apple-converted-space"> </span><b class="">safety</b>, but can be opened up with the<span class="Apple-converted-space"> </span><b class="">open</b><span class="Apple-converted-space"> </span>keyword (which implies public).</div><div class=""><br class=""></div><div class="">If we try to mirror this behaviour (the keywords are just suggestions, not important):</div><div class=""><br class=""></div><div class="">* When<span class="Apple-converted-space"> </span><b class="">internal</b>, enums are exhaustive by default for<span class="Apple-converted-space"> </span><b class="">convenience</b>, but can be opened-up with the<span class="Apple-converted-space"> </span><b class="">partial</b><span class="Apple-converted-space"> </span>keyword</div><div class="">* When<span class="Apple-converted-space"> </span><b class="">public,</b><span class="Apple-converted-space"> </span>enums are non-exhaustive by default for<span class="Apple-converted-space"> </span><b class="">safety</b>, but can be made exhaustive with the <b class="">exhaustive</b> keyword (which implies public).</div></div></div></div></blockquote><br class=""></div><div class="">This is not a correct understanding of the internal/public distinction for classes, though. From inside a module, a public-but-not-open class is still subclassable, and similarly a public-but-not-"closed" enum will still be exhaustively switched. You don't have to worry about your<span class="Apple-converted-space"> </span><i class="">own</i> module changing out from under you.</div></div></blockquote><div class=""><br class=""></div><div class="">Correct. Thanks for the clarification! But you still agree with the argument, right? Convenience for same module enums (exhaustive by default), safety for clients of the module (not-exhaustive when public from outside the module), with the option to be explicit? And what do you think of the idea of having the « exhaustiveness » modifier imply public, like open does?</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Jordan</div><br class=""></div></blockquote></div></div></span></blockquote></div></blockquote><span style="font-family: Helvetica, Arial; font-size: 13px; 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="">_______________________________________________</span><br style="font-family: Helvetica, Arial; font-size: 13px; 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;" class=""><span style="font-family: Helvetica, Arial; font-size: 13px; 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="">swift-evolution mailing list</span><br style="font-family: Helvetica, Arial; font-size: 13px; 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;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica, Arial; font-size: 13px; 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica, Arial; font-size: 13px; 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;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica, Arial; font-size: 13px; 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></body></html>