<div dir="ltr">Yes, sorry, my point was that this consideration isn't spelled out. <div><br></div><div>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.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 16, 2016 at 10:32 AM, Karl <span dir="ltr"><<a href="mailto:razielim@gmail.com" target="_blank">razielim@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> What happens if I want an `internal` subclass of an `open` class?<br>
<br>
</span>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.<br>
<br>
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.<br>
<br>
We might think about creating ‘sealed’ protocols, too.<br>
<span class="HOEnZb"><font color="#888888"><br>
Karl</font></span></blockquote></div><br></div>