[swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly
griotspeak at gmail.com
Sat Jul 16 10:59:22 CDT 2016
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 <razielim at gmail.com> wrote:
> > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution <
> swift-evolution at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution