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

[Matthew Johnson]

> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.
> 
> Actually, I thought the philosophy was to preserver type safety. When did that change?
> 
> Also, when was the library designer prioritised ahead of the application developer?
> 
> 
>> 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.
> 
> No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?

It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses.  It is important to allow libraries to have this flexibility.  They are free to declare a class `open` if they want to allow subclassing.  It’s even possibly for a library to declare all classes `open` if it wishes to do so.  But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.

> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution