<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 Sep 17, 2017, at 3:37 AM, Jonathan Hull 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">I run into use cases like this all the time…<div class=""><br class=""></div><div class="">I think I would prefer to see those concrete cases in a subtype though:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>enum DrinkSize {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case small</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case medium</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case large</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>enum SummerDrinkSize : DrinkSize {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>//Inherits DrinkSize’s cases</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case extraLarge</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><br class=""></div><div class="">Because it is a subtype, you could place a SummerDrinkSize anywhere you can put a DrinkSize. As a result, all switches on it would need a default case to handle cases they hadn’t planned for. If you mark an enum with “<b class="">final</b>” then it can’t be extended and switches can be exhaustive.</div></div></blockquote><div><br></div><div>You have the subtype relationship backwards here. DrinkSize is a subtype of SummerDrinkSize. All values of DrinkSize are also valid values of SummerDrinkSize but not vice versa. For this reason, inheritance syntax doesn't make sense. The syntax that makes more sense is some kind of case embedding syntax:</div><div><br></div><div><div class=""><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">enum SummerDrinkSize {</span></font></div><div class=""><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"><span class="Apple-tab-span" style="white-space: pre;"> </span>cases DrinkSize</span></font></div><div class=""><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"><span class="Apple-tab-span" style="white-space: pre;"> </span>case extraLarge</span></font></div><div class=""><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">}</span></font></div></div><br><blockquote type="cite"><div><div class=""><br class=""></div><div class="">In addition to inheriting the cases, a subtype would also inherit, and be able to override, methods defined on the super-type. You could use super to call the super-type’s implementation. </div></div></blockquote><div><br></div><div>I think implementation sharing is a bad idea for value types. Value subtyping should be conceptualized as a restricted mechanism for value-preserving implicit conversion.</div><br><blockquote type="cite"><div><div class=""><br class=""></div><div class="">It is a bigger overhaul, but I think it actually ends up being semantically simpler for the end user. Basically, you can do the same types of things you can with classes... with the same syntax (just without the reference-type-ness).</div><div class=""><br class=""></div><div class="">It just so happens that this would also solve the problem of adding cases to (non-final) library enums, because switches of the enums would need to handle default/unexpected cases. That is a very abstract/confusing problem for end users who don’t write libraries to understand though. I think it is much easier to explain “final” as being the same as it is in classes, in that it prevents subclassing… which means you know what all the cases are.</div><div class=""><br class=""></div><div class="">More work (also more powerful), but semantically simpler. It just combines concepts we already know...</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Sep 16, 2017, at 3:51 PM, Kenny Leung 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Oops, forgot something:</div><div class=""><br class=""></div><div class="">"Can there be a kind of open enum where you can add new cases in extensions?”</div><div class=""><br class=""></div><div class="">I have a use case for this. I’m trying to write a database ORM with abstract API and concrete instances for different database. So I have defined:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="color: #ba2da2" class="">open</span> <span style="color: #ba2da2" class="">class</span> Database {</div><div style="margin: 0px; font-size: 12px; line-height: normal; background-color: rgb(255, 255, 255); min-height: 14px;" class=""><span style="font-family: Menlo; font-size: 11px;" class=""> </span><span style="font-family: Menlo; font-size: 11px; color: rgb(186, 45, 162);" class="">init</span><span style="font-family: Menlo; font-size: 11px;" class="">(connectionDictionary: [</span><span style="font-family: Menlo; font-size: 11px; color: rgb(79, 129, 135);" class="">ConnectionDictionaryKey</span><span style="font-family: Menlo; font-size: 11px;" class="">:</span><span style="font-family: Menlo; font-size: 11px; color: rgb(112, 61, 170);" class="">String</span><span style="font-family: Menlo; font-size: 11px;" class="">]) {</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""> <span style="color: #ba2da2" class="">self</span>.<span style="color: #4f8187" class="">connectionDictionary</span> = connectionDictionary;</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""> }</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class="">}</div></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><br class=""></div><div style="margin: 0px; line-height: normal; background-color: rgb(255, 255, 255);" class=""><span style="font-family: Helvetica; font-size: 13px;" class="">Where I have ConnectionDictionaryKey defined as an enum, with values like .hostName, .databaseName, .userName, .password, .databaseName, etc</span>…</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-family: Helvetica; font-size: 13px;" class=""><br class=""></span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-family: Helvetica; font-size: 13px;" class="">But concrete databases may have other options that need to be added to the connection dictionary. It would be nice if they could just extend </span><span style="color: rgb(79, 129, 135);" class="">ConnectionDictionaryKey</span> with new cases.</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class="">-Kenny</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 16, 2017, at 3:35 PM, Kenny Leung 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">In general, I agree with everything in the proposal.</div><div class=""><br class=""></div><div class="">I’d like to propose these alternative extensions for clients:</div><div class=""><br class=""></div><div class="">1) As a client of an enum, I’d like to know in the future when a new value has been added to an enum, since I may have to do something about it. How about adding the “exhaustive” keyword to be used in the switch statement? Like</div><div class=""><br class=""></div><div class="">exhaustive switch excuse {<br class=""> case eatenByPet:</div><div class=""> // …</div><div class=""> case thoughtItWasDueNextWeek:<div class=""> // …</div><div class=""> default:</div><div class=""> // …</div>}</div><div class=""><br class=""></div><div class="">If exhaustive is used, there would be a warning if all cases aren’t covered *even though default exists*. This means that I as the client thought I had everything covered when I wrote this code.</div><div class=""><br class=""></div><div class="">As already mentioned, this makes the default case un-testable, which brings me to</div><div class=""><br class=""></div><div class="">2) All non-exhaustive enums should have the pseudo value “default” that can be used just like a regular value. This would allow you to write code like:</div><div class=""><br class=""></div><div class="">teacher.failedToHandInHomework(excuse: .default)</div><div class=""><br class=""></div><div class="">which would allow you to trip the default case in any code you may write.</div><div class=""><br class=""></div><div class="">-Kenny</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Sep 13, 2017, at 12:17 PM, Jordan Rose 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Proposal updated, same URL: <a href="https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md" class="">https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md</a>.</div><div class=""><br class=""></div><div class="">Thanks again for all the feedback so far, everyone!</div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 12, 2017, at 17:55, Jordan Rose 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 class="">Sorry, I got distracted by other tasks! Both the discussion here and within Apple has moved towards making "non-exhaustive" the default, which, to be honest, I too think is the best design. I'll update the proposal today to reflect that, though I still want to keep both the "nonexhaustive" and "exhaustive" keywords for Swift 4 compatibility for now (or whatever we end up naming them). The compatibility design is a little less ambitious than Brent's; as currently proposed, Swift 4 mode continues to default to 'exhaustive' all the time, even in the actual Swift 5 release.<br class=""><br class="">I still want to respond to Brent's points directly, but I think you and Vladimir have done a good job discussing them already. I'll send out the updated proposal tomorrow, after I have a little more time to think about #invalid.<br class=""><br class="">Thanks for putting time into this!<br class="">Jordan<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Sep 9, 2017, at 17:34, Rod Brown <<a href="mailto:rodney.brown6@icloud.com" class="">rodney.brown6@icloud.com</a>> wrote:<br class=""><br class="">Jordan,<br class=""><br class="">Do you have any other thoughts about the ongoing discussion here, especially regarding Chris’ comments? As you’re the one pushing this forward, I’d really like to know what your thoughts are regarding this?<br class=""><br class="">- Rod<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></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>