> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution > <[email protected]> wrote: > > >> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution >> <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
