<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br><div>Regards</div>(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "> mobile)</span></div><div><br>On Jul 16, 2016, at 9:17 PM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div><blockquote type="cite" class=""><div class="">On Jul 16, 2016, at 11:48 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class="">On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jul 16, 2016, at 11:03 AM, T.J. Usiyan <<a href="mailto:griotspeak@gmail.com" target="_blank" class="">griotspeak@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class=""><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px" class=""><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">"open</code> is invalid on declarations that are not also <code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">public</code> (see the Alternatives discussion for rationale)."</p></div><div class="">+</div><div class=""><br class=""></div>"<span style="color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px" class="">If an </span><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;color:rgb(51,51,51)" class="">open</code><span style="color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px" class=""> class inherits an </span><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;color:rgb(51,51,51)" class="">open</code><span style="color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px" class=""> method from a superclass, that method remains </span><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;color:rgb(51,51,51)" class="">open</code><span style="color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px" class="">. If it overrides an </span><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;color:rgb(51,51,51)" class="">open</code><span style="color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px" class=""> method from a superclass, the override is implicitly </span><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;color:rgb(51,51,51)" class="">open</code><span style="color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px" class=""> if it is not </span><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;color:rgb(51,51,51)" class="">final</code><span style="color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px" class="">.</span>"<div class=""><br class=""></div><div class="">I understand that the intent is probably not to say that subclasses are public by default. My point is that those two statements, without an explicit spelling out of the implicit access level, could lead me to believe that subclasses are implicitly public by default. It is open to interpretation. Neither the prose nor the code examples address it.</div></div></div></blockquote><div class=""><br class=""></div></span>I see your general point. I'll think about how to re-word this; it may be sufficient to just remove the requirement that open methods appear in open classes. Suffice it for me to say now, officially, that this proposal does not require classes to be public or open just because they override open methods from an open superclass.</div></div></blockquote><div class=""><br class=""></div><div class="">It might be barely sufficient solely to remove the requirement that open methods appear in open classes. However, if my subclass is internal, I shouldn't be required to declare a `public override` of an open method just to satisfy the rules for `open`, which would be forced by the rule that `open` is invalid on declarations that are not also `public`</div></div></div></div></div></blockquote><div><br class=""></div><div>This rule only applies to explicit uses of "open". A method that is implicitly open due to overriding does not have this restriction.</div><div><br class=""></div><div>In general, my intent in writing this proposal was to cover the important interactions, not to write a fully precise specification. The general rule about overrides having to be at least as accessible as the minimum of their class and their overridden method still applies, superseded only by the rule that it is acceptable to drop the "open" on a public open override.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">combined with the rule that overrides of an open method are by default open.</div></div></div></div></div></blockquote><div><br class=""></div></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">This would degrade the developer experience significantly, since a beginning developer writing only internal subclasses for their own app would now be required to litter either `public override` or `final override` throughout their code in the ordinary course of subclassing. On reconsideration, it might be best if overrides are not implicitly open.</div></div></div></div></div></blockquote><br class=""></div><div>I continue to think "override" is sufficient communication here. We're not going to have a model where the inherited open API of the superclass becomes non-open in the subclass.</div></div></blockquote><div><br></div><div>the logic of the proposal would dictate that it did: by subclasing the original type into a new type, the programmer is effectively removing any of the original guaranties that the first programmer made about how cohesively all paths into the type operated. The new code defines a new outer boundary for the subtype that has every reason not to be trusted by default to be working for subclasing, for the same reasons the original types could not be implicitely trusted either.</div><div><br></div><blockquote type="cite"><div><div> We don't want the mere existence of an override in the subclass to change that because it's a fairly core goal that the existence of an override (at least one which doesn't covariantly refine the type) in a subclass should not affect source/binary compatibility.</div><div><br class=""></div><div>John.</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="h5"><div class=""><br class=""></div><div class="">John.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Jul 16, 2016 at 1:35 PM, John McCall <span dir="ltr" class=""><<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">Sent from my iPhone</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class="">On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class=""><div dir="ltr" class="">Yes, sorry, my point was that this consideration isn't spelled out. <div class=""><br class=""></div><div class="">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></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">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.</div></div></blockquote><div class=""><br class=""></div></span>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.</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">John.</div></font></span><span class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Jul 16, 2016 at 10:32 AM, Karl<span class=""> </span><span dir="ltr" class=""><<a href="mailto:razielim@gmail.com" target="_blank" class="">razielim@gmail.com</a>></span><span class=""> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br class="">> On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">><br class="">> What happens if I want an `internal` subclass of an `open` class?<br class=""><br class=""></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 class=""><br class="">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 class=""><br class="">We might think about creating ‘sealed’ protocols, too.<br class=""><span class=""><font color="#888888" class=""><br class="">Karl</font></span></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">swift-evolution mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="mailto:swift-evolution@swift.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">swift-evolution@swift.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></span></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>