> On Feb 14, 2017, at 6:16 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > So, perhaps I'm being simplistic here, but-- > > At the end of the day, aren't we simply trying to enable a resiliency > feature? Could it not be said that an enum where future added cases aren't > source-breaking is a more resilient enum? > > Since there is consensus that the status quo is desirable for a lot of use > cases, couldn't we keep spelling it "public enum" and just spell this > proposed more resilient enum "@resilient public enum"?
Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer. Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option. Resilient enums are definitely the more flexible option, so by that rule, they should have plain `public`. I think that, if enums were a brand-new feature being introduced for the first time in Swift 4, there would be no question that `public enum` ought to give you a resilient enum. The only good reason not to do that is source compatibility. So we need to decide: Which of these principles is more important to us? 1. "Defaults for public symbols should preserve as much flexibility for designers as possible." 2. "Swift 3 code should compile in Swift 4 without deprecation warnings, unmodified and without a version compatibility flag, whenever possible." -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
