> On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote: > Sent from my iPhone > > On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> Yes, sorry, my point was that this consideration isn't spelled out. >> >> Another question is whether or not making a subclass of an open class public >> by default is what we want. I see why it would be, I just think that it is a >> wrinkle to default to internal otherwise but not here. > > I can't think of any good reason to assume a specific class should be public > just because it is a subclass of an open class. The internal default would > still be the right default in this case.
Right, there's no new restriction here. Of course you can make a private or internal subclass of a public open class — otherwise, you'd have to publicize every subclass of (say) UIViewController. John. > >> >> On Sat, Jul 16, 2016 at 10:32 AM, Karl <razie...@gmail.com >> <mailto:razie...@gmail.com>> wrote: >> >> > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution >> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> > >> > What happens if I want an `internal` subclass of an `open` class? >> >> That should be allowable. You may want some optimised implementations, >> similar to how Apple used class-clusters in Obj-C. I don’t think that same >> pattern is exactly possible in Swift (I don’t think a class can set ‘self’ >> in its initialiser, or at least it couldn’t in Swift 1). But the same >> principle applies - you may want a public class which you don’t allow others >> to subclass, but you might have a static method or other function which >> returns an internal optimised implementation. >> >> If you used a protocol rather than a concrete type in that case, >> theoretically others could conform to it and throw their own objects back at >> your code, which goes against the point of this proposal. >> >> We might think about creating ‘sealed’ protocols, too. >> >> Karl >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
