<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 16, 2016, at 9:49 AM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Can you not see the links to the rest of the corelibs changes in the discussion? Then I'll reproduce them here</div></div></div></blockquote><div><br class=""></div>Thanks. I don’t see anything unexpected here. The Swift PM case is one where the team wishes to take advantage of SE-0025 to tighten visibility and express their intent more explicitly. </div><div><br class=""></div><div>The automated find / replace migration you applied is correct, but maybe they want to slow down and review the changes so the results match the semantics they desire. That seems reasonable to me.</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">- SwiftPM</div><div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift-package-manager/pull/410" class="">https://github.com/apple/swift-package-manager/pull/410</a></div><div class=""><br class=""></div>- XCTest<div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift-corelibs-xctest/pull/124" class="">https://github.com/apple/swift-corelibs-xctest/pull/124</a></div><div class=""><br class=""></div><div class="">- Foundation</div><div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift-corelibs-foundation/pull/413" class="">https://github.com/apple/swift-corelibs-foundation/pull/413</a></div><div class=""><br class=""></div><div class=""><div class=""><br class=""><div class="">~Robert Widmann</div></div><div class=""><br class="">2016/06/16 7:35、Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 16, 2016, at 9:30 AM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Find it under our own pull requests on apple/swift#3000<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">You mean this one: <a href="https://github.com/apple/swift/pull/3000" class="">https://github.com/apple/swift/pull/3000</a> right?</div><div class=""><br class=""></div><div class="">What specifically did you want me to look at here? Of course this proposal is going to require a lot of changes to existing code (changing `private` to `fileprivate`). That was vetted and accepted during the review process. I don’t see how this is relevant to the current thread. Is there some other part of the discussion I am not seeing?</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">~Robert Widmann<br class=""><br class="">2016/06/16 7:28、Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> のメッセージ:<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On Jun 16, 2016, at 9:23 AM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:<br class=""><br class="">Go checkout my branch! And see the discussion there for how your proposal has impacted corelibs.<br class=""></blockquote><br class="">I’ll be happy to. Can you please provide a link to the branch and discussion?<br class=""><br class=""><blockquote type="cite" class=""><br class="">~Robert Widmann<br class=""><br class="">2016/06/16 5:50、Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> のメッセージ:<br class=""><br class=""><blockquote type="cite" class=""><br class=""><br class="">Sent from my iPad<br class=""><br class="">On Jun 16, 2016, at 5:20 AM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">6. With the core team tied up at WWDC, you may want to temporarily forbid the use of `private` on a type and revisit the matter when people are less busy; if necessary, we could even ship Swift 3 that way. Or you may want to consider making a guess as to a good implementation model to apply. Two suggestions for alternate implementation models:<br class=""><br class="">a. Introduce a `parent` access level, meaning "visible in scopes within this file where the parent is visible", which is between `fileprivate` and `private`. Just as `internal` is the maximum inherited access level, `parent` is the minimum, so the members of a `private` type would inherit `parent` visibility. `parent` might be an entirely compiler-internal concept, with no utterable access control keyword.<br class=""></blockquote><br class="">Thinking about this more, I notice that `fileprivate` as currently defined doesn't actually make any sense to say inside a `private` type: if your parent type has less-than-file-wide visibility, nothing in the file that's outside its scope can see you anyway. Therefore, we could redefine `fileprivate` thusly:<br class=""><br class="">1. A member with `fileprivate` visibility is visible within the scope in which the nearest containing `private` type is visible.<br class="">2. If there are no containing `private` types, it is visible within the file containing it.<br class="">3. Just as the members of a `public` type are `internal`, so the members of a `private` type are `fileprivate`.<br class=""><br class="">This kind of suggests that we ought to rename `fileprivate` to something that, y'know, doesn't say "file" in it. However, I can scarcely imagine the results of a round of bikeshedding without parental supervision from the core team, so I don't dare make any suggestions.<br class=""></blockquote><br class="">I am not convinced this is necessary. If there *is* a containing 'private' scope you can just leave the member unannotated to get this behavior. If there isn't you can use 'fileprivate' as it is already defined. Why is that not sufficient?<br class=""><br class="">If you really want a second, more nuanced and complex scope-dependent access control mechanism I think you'll need to submit a proposal for it. A simple renaming to 'fileprivate' is what has been accepted thus far. <br class=""><br class="">The main argument for what you suggest is that it would provide a way to ensure visibility of the member is*never* more than the file, but is as visible as possible within the file, while being less sensitive to changes in visibility of surrounding scopes. IMO we need to get some experience with SE-0025 in real code before we know whether this is a problem that needs solving or not.<br class=""><br class="">-Matthew<br class=""><br class=""><blockquote type="cite" class=""><br class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote></blockquote></blockquote><br class=""></blockquote></div></div></blockquote></div><br class=""></div></blockquote></div></div></div></blockquote></div><br class=""></body></html>