On Aug 6, 2015, at 09:20 , Jens Alfke <j...@mooseyard.com> wrote: > > You can't do that, because instances of the subclassed enum won’t be valid > instances of the super-enum.
I’m not sure that subclassing is what’s being asked for here. It seems like it would be useful to be able to define a new enum that has the same cases as an existing enum plus some more cases. These two enums would be separate types, so there’s no confusion. The only special relationship is that (perhaps) it would be legal to assign a variable of the original enum to a variable of the derived enum, since the cases would correspond, but this would be resolved at compile time, not run time. On Aug 6, 2015, at 10:38 , Rick Mann <rm...@latencyzero.com> wrote: > > But we need some kind of extensible way of defining a set of valid selectors Possibly, but carrying selectors forward into Swift’s future seems like a bad idea. Selectors are an ambiguous way to refer to methods, and that has some advantages as well as some disadvantages. Swift has better mechanisms for most things that selectors are used for, such as closures and partial method application, not to mention enums with associated values. The only real “poor fit” I’ve found so far is that you can test selectors for equality, but there’s no == (or ===) operator for closures. As it happened, the micro-redesign I had to do to solve that produced a much better solution overall. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
