[swift-evolution] [Pitch] consistent public access modifiers
brent at architechies.com
Wed Feb 15 05:11:32 CST 2017
> On Feb 14, 2017, at 6:16 PM, Xiaodi Wu <xiaodi.wu at 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."
More information about the swift-evolution