<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 16, 2017, at 15:35, 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></div></blockquote><br class=""></div><div>Brent came up with this idea as well, but after thinking it through Joe Groff and I found that it doesn't really work in practice:</div><div><br class=""></div><div><div class=""></div><blockquote type="cite" class=""><div class="">It’s going to be very common to have a future value and hand it right back to the framework without looking at it, for example:</div><div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class="">override func process(_ transaction: @testable Transaction) {</div><div class=""> switch transaction {</div><div class=""> case .deposit(let amount):</div><div class=""> // …</div><div class=""> case .withdrawal(let amount):</div><div class=""> // …</div><div class=""> default:</div><div class=""> super.process(transaction) // hmm…</div><div class=""> }</div><div class="">}</div></blockquote><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><br class=""></div><div class="">So just making it to the ‘default’ case doesn’t guarantee that it’s testable in practice.</div></div></div></blockquote><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><br class=""></div></div></div></div>I'll add the actual code here to the "Testing invalid cases" section under "Alternatives considered", since that's a clearer example than the paragraph I wrote. (Oh, and the "exhaustive switch" is equivalent to the section on "'future' cases".)<div class=""><br class=""></div><div class="">Thanks for the feedback!</div><div class="">Jordan</div></body></html>