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.
On Sat, Jul 16, 2016 at 10:32 AM, Karl <[email protected]> wrote: > > > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution < > [email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
