<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="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md</a>]<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 21, 2017, at 09:49, Ignacio Soto 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="">
<title class=""></title>
<div class="">
<div name="messageBodySection" class=""><font color="#454545" class="">I think I speak for the entire Swift community when I say that Swift's enums, together with the ability to switch over them exhaustively and having compile-time guarantees, is one of the best features in Swift. I'm regularly annoyed by this when writing other languages like Java and JS (<i class="">default: throw new IllegalArgumentException();</i>)<br class="">
<br class="">
Now, that's not to say I don't understand why this proposal is necessary. I totally get it, and the existing decisions make a lot of sense to me. But I'd like us to introduce this while maintaining the ability to guarantee exhaustive <i class="">switch</i> statements, no matter how the enum was defined.<br class="">
<br class="">
Example: imagine a theoretical <i class="">SampleKit</i> defines:<br class="">
public enum E {<br class="">
case A<br class="">
case B<br class="">
}<br class="">
<br class="">
It's implicitly <i class="">non-exhaustive</i>, possibly because the author was not aware of the default (which would likely happen often), or possibly because they made a conscious decision, as they expect to expand the cases in the future.<br class="">
<br class="">
In my app, I use <i class="">SampleKit</i> and decide that I want to make sure I handle all cases:<br class="">
<br class="">
switch e {<br class="">
case A: break<br class="">
case B: break<br class="">
default: break // This becomes necessary<br class="">
}<br class="">
<br class="">
As the proposal stands right now, I'm forced to handle any future cases. That's fine. <b class="">What's not fine in my opinion, is that in doing so I lose the ability to keep this exhaustiveness moving forward</b>. If I update <i class="">SampleKit</i> to v2.0, I want to know at compile-time if there are new cases I need to be aware of (instead of going to some generic handling path). Instead, I’m left in the same place I would in other languages like Java or JS:<br class="">
<br class="">
// No error :(<br class="">
switch e {<br class="">
case A: break<br class="">
case B: break<br class="">
default: break<br class="">
}<br class="">
<br class="">
<b class=""><u class="">Proposed Solution</u></b><br class="">
<br class="">
What I’m proposing is that we introduce a new keyword, <i class="">unknown</i> (or a better name), that serves as a way to handle cases that aren’t yet known, but not those that are.<br class="">
<br class="">
// Error: missing case C<br class="">
switch e {<br class="">
case A: break<br class="">
case B: break<br class="">
unknown: break // Would handle future cases<br class="">
}<br class="">
<br class="">
With this, you shouldn’t be able to use <i class="">default</i> AND <i class="">unknown</i> at the same time, as <i class="">default</i> implicitly includes <i class="">unknown.</i><br class="">
<br class="">
Thanks for reading, and I hope you can consider this change (or some variation of it).</font></div>
</div></div></blockquote></div><br class=""><div class="">Hi, Nacho. This is discussed in the proposal as "'future' cases" under "Alternatives considered". The main blocker was that such a case becomes untestable (see also "Testing invalid cases"). That didn't seem like an acceptable state of affairs to me or to the people I had originally discussed the proposal with, but maybe the community feels differently?</div><div class=""><br class=""></div><div class="">I would love if someone could think of something I haven't yet; by no means do I think I'm the only one who can have ideas in this space.</div><div class=""><br class=""></div><div class="">Jordan</div></body></html>