<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>On Dec 21, 2017, at 9:49 AM, Ignacio Soto via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>
<title></title>
<div name="messageBodySection"><font color="#454545">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>default: throw new IllegalArgumentException();</i>)<br>
<br>
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>switch</i> statements, no matter how the enum was defined.<br>
<br>
Example: imagine a theoretical <i>SampleKit</i> defines:<br>
public enum E {<br>
case A<br>
case B<br>
}<br>
<br>
It's implicitly <i>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>
<br>
In my app, I use <i>SampleKit</i> and decide that I want to make sure I handle all cases:<br>
<br>
switch e {<br>
case A: break<br>
case B: break<br>
default: break // This becomes necessary<br>
}<br>
<br>
As the proposal stands right now, I'm forced to handle any future cases. That's fine. <b>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>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>
<br>
// No error :(<br>
switch e {<br>
case A: break<br>
case B: break<br>
default: break<br>
}<br>
<br>
<b><u>Proposed Solution</u></b><br>
<br>
What I’m proposing is that we introduce a new keyword, <i>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>
<br>
// Error: missing case C<br>
switch e {<br>
case A: break<br>
case B: break<br>
unknown: break // Would handle future cases<br>
}<br>
<br></font></div></div></blockquote><br>What are your thoughts on `final switch` as a way to treat any enum as exhaustible?<div><a href="https://dlang.org/spec/statement.html#FinalSwitchStatement">https://dlang.org/spec/statement.html#FinalSwitchStatement</a><br><div><br></div><div><div><br><blockquote type="cite"><div><div name="messageBodySection"><font color="#454545">
With this, you shouldn’t be able to use <i>default</i> AND <i>unknown</i> at the same time, as <i>default</i> implicitly includes <i>unknown.</i><br>
<br>
Thanks for reading, and I hope you can consider this change (or some variation of it).</font></div>
<div name="messageSignatureSection"><br>
<div class="matchFont">Nacho Soto</div>
</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></div></div></div></body></html>