> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > >> 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. >
Why would a library author want to prohibit subclasses? A library user can always wrap the class and subclass the wrapper. There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users. Rien. >> >> >> _______________________________________________ >> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
