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

[Matthew Johnson]

> On Feb 15, 2017, at 5:11 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> 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.”

It’s also worth re-iterating the point I have made about inconsistent semantics for `public`, and that this problem as well as your first point also impacts protocols.  That means we have two reasons to make a change and both impact protocols and enums.  We also have a very reasonable way to introduce the changes necessary to solve these problems.

I think the changes are worth making, and certainly worthy of at least bringing a proposal to review.

> 
> -- 
> Brent Royal-Gordon
> Architechies
>