
<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title></title>

</head>

<body>

<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 />

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>

</body>

</html>