<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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) which would allow us to create sub/supertypes 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; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I want to modify your main idea into:</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">(Potentially possible in the future)</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">- open-but-finite enum - or simply: open finite enum</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">- open-but-infinite enum - or simply: open enum</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">(Version that we could make possible in Swift 5)</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">- public-but-finite enum - or simply: public finite enum</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">- public-but-infinite enum - or simply: public enum</div> <br> <div id="bloop_sign_1502396328534311168" class="bloop_sign"></div> <br><p class="airmail_on">Am 10. August 2017 um 22:00:40, David Hart (<a href="mailto:david@hartbit.com">david@hartbit.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div dir="auto"><div></div><div>
<title></title>
<br>
<div><br>
On 10 Aug 2017, at 19:19, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>>
wrote:<br>
<br></div>
<blockquote type="cite">
<div>
<br class="">
<div><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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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 style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<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", <i class="">something</i> is
redundant here. Still, I'm uncomfortable with the default case
being the one that constrains library authors, so at <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 <b class="">internal</b>, classes are
sub-classable by default for <b class="">convenience</b>, but can
be closed with the <b class="">final</b> keyword</div>
<div class="">* When <b class="">public</b>, classes are closed to
sub-classing for <b class="">safety</b>, but can be opened up with
the <b class="">open</b> 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 <b class="">internal</b>, enums are exhaustive
by default for <b class="">convenience</b>, but can be opened-up
with the <b class="">partial</b> keyword</div>
<div class="">* When <b class="">public,</b> enums are
non-exhaustive by default for <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>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 <i class="">own</i> module
changing out from under you.</div>
</div>
</blockquote>
<div><br></div>
<div>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>
<blockquote type="cite">
<div>
<div>Jordan</div>
<br class=""></div>
</blockquote>
</div></div></span></blockquote></body></html>