[swift-evolution] [Proposal] Powerful enumerations built upon protocols, structures and classes

[Marc Knaup]

Thank you for your extensive feedback.

The way I proposed it is actually the other way round:
Switches over enumerations still don't need a default case since all cases
(i.e. types conforming to them) are known at compile-time.
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.

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.

On Tue, Dec 15, 2015 at 2:59 PM, Al Skipp <al_skipp at fastmail.fm> wrote:

> > Sum types look very interesting and are very similar to enumerations.
> > 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.
> > It could also be proposed separately or on top of this proposal.
> > In any case this proposal does not prevent sum types from being added to
> Swift.
>
>
>
> 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?
>
> 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.
>
> 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.
>
> That’s why I think the distinction between enums and protocols is
> important - enums are useful because they’re not extensible.
> 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.
>
> My worry is this proposal would reduce compile time guarantees in Swift
> and make me more responsible for finding my own bugs (the horror!).
>
> Al
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/2259cd48/attachment.html>