<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">To be clear, I agree that there is a problem. I just perceive it as a documentation problem more than as an access control problem.<div class=""><br class=""></div><div class="">There are at least 2 other proposals that suggest(ed?) a more complex access control model (`private(extension)`, `private(objc)`), and I don't like adding exceptions to `private`.</div><div class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 12 janv. 2016 à 16:43:39, Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">On 2016-01-12 13:50, Michel Fortin wrote:<br class=""><blockquote type="cite" class="">Le 11 janv. 2016 à 19:53, Charles Srstka via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :<br class=""><blockquote type="cite" class="">What do you think?<br class=""></blockquote>The idea looks good to me on the surface. But the details are awkward.<br class="">First, if you can't call the super implementation from an override,<br class="">there is no need to require that the overriding function be<br class="">private(call) because all it will contain is client code that can't<br class="">call the library's implementation. So the derived class can make the<br class="">function more visible by reimplementing it.<br class=""></blockquote><br class="">My thinking is that if the subclass wants to make the functionality behind the method more visible, it's better to just spin it off into a separate method rather than ask callers to get used to calling a method that, according to the API contract of the superclass, is more an implementation detail than a part of the external interface.<br class=""><br class=""><blockquote type="cite" class="">But that's not the common case. In general you want to allow the<br class="">overriding function to call the super implementation. So...<br class="">Second, if you allow a call to the super implementation from an<br class="">override, then you need to make that overriding function uncallable by<br class="">anyone. Only the base class can call it using virtual dispatch. You<br class="">can't call it even from the same file, so it's *less visible than<br class="">private*.<br class="">That's a bit weird.<br class=""></blockquote><br class="">It may be a bit weird, but it is what the API contract is already asking the class to do. It's just that currently, it's not enforced other than in documentation.<br class=""><br class="">I should point out that we, essentially, already have methods like this; Swift initializers, unlike init methods in Objective-C, are similarly invisible; they cannot be called by any other code, even in the same file, unless that code is marked as a convenience initializer. Deinit, likewise, can't be called by anything except for the Swift runtime itself.<br class=""><br class="">Charles<br class=""><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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>