[swift-evolution] [Pitch] consistent public access modifiers

[Brent Royal-Gordon]

> 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."

-- 
Brent Royal-Gordon
Architechies