<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Comments inline.</div><div><br>On Jun 28, 2016, at 04:14, David Hart 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">Hello everybody,<div class=""><br class=""></div><div class="">I tried using the access rules defined in SE-0025 in some code of mine to see what effect it would have. I came out of the experiment more disappointed than I thought. Here are several reasons:</div><div class=""><br class=""></div><div class="">1) The new rules make `private` more prominent compared to `fileprivate` (the latter has a somewhat worse name). But at the same time, the Swift community has developed a style of coding where a type is defined through a set of extensions. To hide members from other types, but have access to them inside the type extensions, we have often used `private` and placed the type and its extensions in the same file. Because `private` is scoped, we are forced into using `fileprivate` pervasively (which is uglier), using `internal` instead (which is less safe) or moving the extension code into the type's scope (which is against the way Swift code is being written today). All of these options look worse to be than before SE-0025.</div></div></blockquote><div><br></div>If I understand SE-0025 (even with the amendment) you can still spell the access modifier to types as 'private' and get the same characteristics as the pre-SE-0025 meaning or private, so I'm not sure I understand the concern here. However (continued below)<br><blockquote type="cite"><div><div class=""><br class=""></div><div class="">2) The new amended rules look complicated to me. I think they have the risk of being confusing in practice, but we’ll have to see.</div><div class=""><br class=""></div></div></blockquote><div><br></div><div>I definitely agree that the amended rules look complicated. It seems to me that the amended set of rules is favoring simplifying the implementation over simplifying the mental model.</div><div><br></div><div>My impression of what SE-0025 decided was that 'private' meant private to the enclosing scope. If the access modifying 'private' was applied to a type at the file scope, then it was synonymous with fileprivate and the default access of members of that type should be fileprivate.</div><div><br></div><div>If a inner type was declared private, than the default access of members of that inner type should be private to the Outer type, not fileprivate. There is currently no way of expressing this access explicitly, but it does not seem like an especially useful thing to need to spell.</div><div><br></div><div>Said in code, my impression of SE-0025 is that </div><div><br></div><div>private class Outer { // exactly equivalent to fileprivate</div><div> var myVar = 0 // default: fileprivate</div><div> private class Inner { // private to Outer</div><div> var hiddenVar = 0 // default: private to Outer</div><div> private var reallyHiddenVar = 0 // default private to Inner</div><div> }</div><div>}</div><div><br></div><blockquote type="cite"><div><div class="">More generally, I think that the scoping rules of `fileprivate` may have an in insidious effect that favour moving code back into the type’s scope instead of preferring the cleaner style of putting it into extensions.</div><div class=""><br class=""></div><div class=""><b class="">Potential solution:</b></div><div class=""><br class=""></div><div class="">What is `private` members were also visible to all extensions of the type in the same module?</div></div></blockquote><div><br></div>Disagree with this solution... It seems like a complete rework of the mental model for access modifiers. None of the existing access modifiers work on types.<div><br><blockquote type="cite"><div><div class=""><br class=""></div><div class="">David.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 28 Jun 2016, at 01:19, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Robert and I wrote up the changes in the form of an amendment to SE-0025: <a href="https://github.com/apple/swift-evolution/pull/383" class="">https://github.com/apple/swift-evolution/pull/383</a>. Please let me know if we missed anything!</div><div class=""><br class=""></div><div class="">I talked briefly to Chris and he said the core team will decide whether it needs a full review period, or whether it counts as the “obvious” semantics and can thus be accepted without a formal review.</div><div class=""><br class=""></div></div></div></blockquote></div></div></div></blockquote><div><br></div><div>My apologies for getting a bit long winded so far, hopefully I'm not just rehashing the previous arguments.</div><div><br></div><div>In regards to Alternative 2 for "the private type issue" and creating an access modifier named 'parent' or leaving that access level as without a way to express it: I believe it is acceptable not to add the term. I would expect the most likely situation for this needing to be spelled would be a type accessable to the module with a member only visible to the file. This can already be expressed by fileprivate. </div><br><blockquote type="cite"><div><div class=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Jordan</div></div>_______________________________________________<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">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></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></div></body></html>