<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Regards<br>(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.294118);"> mobile)</span></div><div><br>On Jul 18, 2016, at 9:53 PM, Károly Lőrentey 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">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="1490.23">
<p class="p1">If people were generally happy with having public members of open classes overridable by default, then we certainly wouldn't need to have a separate qualifier for that. (Although as "internal" demonstrates, it's nice to have a formal name for such things.)</p>
<p class="p2"><br></p>
<p class="p1">However, (1) having a default would allow API designers to define public APIs with very little additional thought, and (2) it seems to me we're very very far from consensus on which default would be best. I'd like to avoid arguing even more about the theoretical merits of choosing open vs final vs dynamic by default. (Note that there are highly respectable app developers who honestly consider "open" much too restricting.)</p>
<p class="p2"><br></p>
<p class="p1">I'm enthusiastic about sealed-by-default classes, but to be honest, I personally have no idea what default (if any) would be best for class members. Ask me again after I've worked with the new classes for a couple of months.</p></div></blockquote><div>This is what i find so unique about this situation: there is not 2 months to decide, there is not a couple of implementations to compare.. there is here and now to decide for the next 20 years, with zero experience with the api and very little external references (which nobody seems to have sahed any practical experience with) ... nonetheless it must all be fleshed out before the 28th. I cincerely hope the core team is more prepared than they currently let out.</div><div><br></div><div><br></div><blockquote type="cite"><div>
<p class="p2"><br></p>
<p class="p1">Karoly</p>
<p class="p1">@lorentey</p>
<p class="p2"><br></p>
<p class="p1">On 2016-07-18 18:45:14 +0000, Nevin Brackett-Rozinsky via swift-evolution said:</p>
<p class="p2"><br></p>
<p class="p3"><span class="s1">Garth makes an excellent point. Károly is correct that we can already achieve “sealed” by making a `final` member call through to an `internal` one.</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">Therefore, it seem clear that “open” should only be applicable to classes, not to members. This should simplify the proposal nicely.</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">Nevin</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p5"><span class="s1">On Mon, Jul 18, 2016 at 2:39 PM, Garth Snyder via swift-evolution </span><span class="s2"><<a href="mailto:swift-evolution@swift.org"><span class="s3">swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org</span></a>></span><span class="s1"> wrote:</span></p>
<p class="p5"><span class="s1">> Károly wrote: I suggest we change the proposal to remove the implicit "sealed" level of public member overridability, and support only "open" or "final" class members. For members, "open" should mean the opposite of "final", with no levels in between. Member-level openness should be entirely independent of visibility; so it should be possible to say "internal open" to mean an internally overridable member that's not at all visible outside the module -- the same as today's default.</span></p>
<p class="p6"><span class="s1"></span><br></p>
<p class="p5"><span class="s1">What is the distinction between this approach and simply omitting the ability to apply the “open” keyword to anything but a class?</span></p>
<p class="p6"><span class="s1"></span><br></p>
<p class="p5"><span class="s1">The current behavior is (IIUC) that you cannot override a superclass’s final method. Aside from that, you can override any other method that’s visible to you, wherever you stand with regard to the superclass’s origin. If there’s no sealed status for members, why is any change to member annotations needed at all?</span></p>
<p class="p6"><span class="s1"></span><br></p>
<p class="p5"><span class="s1">Garth</span></p>
</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>