<div dir="ltr">Thank you for your extensive feedback.<div><br></div><div>The way I proposed it is actually the other way round:</div><div>Switches over enumerations still don't need a default case since all cases (i.e. types conforming to them) are known at compile-time.</div><div>The same benefit will become available also to other protocols. If a protocol is not public (or not publicly conformable) then the compiler again knows all types explicitly declaring conformance to that protocol at compile-time and the developer can omit a default case when switching over instances of that protocol.</div><div><br></div><div>So the behavior of Swift 2.1 regarding switches and default cases for enumerations remains the same while for many protocols the compiler can additionally issue a warning that the default case is unreachable and thus unnecessary.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 15, 2015 at 2:59 PM, Al Skipp <span dir="ltr"><<a href="mailto:al_skipp@fastmail.fm" target="_blank">al_skipp@fastmail.fm</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb">> Sum types look very interesting and are very similar to enumerations.<br>
> If there is enough interest in sum types then this proposal could probably cover them too since it already provides a good foundation for implementing them.<br>
> It could also be proposed separately or on top of this proposal.<br>
> In any case this proposal does not prevent sum types from being added to Swift.<br>
<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">Swift already has Sum types, they are enums. Pretty much all the other constructs are Product types (structs, classes, tuples…). I’ve not managed to read your detailed proposal in full, but it strikes me that it would involve quite fundamental changes. Not sure what all the consequences would be and what the value is in blurring the distinction between Sum types and Product types?<br>
<br>
My personal view is that the distinction between enums and protocols is important. Your proposal would enable the easy creation of extensible enums which I find problematic. When using extensible enums you’d be obliged to include a ‘default’ case in every switch statement. You point out that you’d be able to restrict the cases by using ‘final’ or some other means, but in practice I think the extensible form would be popular for its perceived flexibility.<br>
<br>
Currently if I create an enum I am obliged to deal with all cases in a switch (assuming I don’t use a default case, which I try to avoid). Now imagine I subsequently realise I need to add a case to the enum. OK, I do so, now all my code breaks, arghh! But this is a good thing! The compiler guides me to every piece of code I need to change – magic! If on the other hand, enums were easily extensible, I’d add my new case and my code would still compile, brilliant! However, my code is fundamentally broken and I have to manually fix it without any guidance from the compiler.<br>
<br>
That’s why I think the distinction between enums and protocols is important - enums are useful because they’re not extensible.<br>
When a type is required that can be extended with new cases, then a protocol is the right tool for the job, rather than an enum.<br>
<br>
My worry is this proposal would reduce compile time guarantees in Swift and make me more responsible for finding my own bugs (the horror!).<br>
<br>
Al</div></div></blockquote></div><br></div>