<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:30 AM, Robert Widmann &lt;<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>&gt; 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><br class=""></div><div>You mean this one:&nbsp;<a href="https://github.com/apple/swift/pull/3000" class="">https://github.com/apple/swift/pull/3000</a>&nbsp;right?</div><div><br class=""></div><div>What specifically did you want me to look at here? &nbsp;Of course this proposal is going to require a lot of changes to existing code (changing `private` to `fileprivate`). &nbsp;That was vetted and accepted during the review process. &nbsp;I don’t see how this is relevant to the current thread. &nbsp;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 &lt;<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>&gt; のメッセージ:<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On Jun 16, 2016, at 9:23 AM, Robert Widmann &lt;<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>&gt; wrote:<br class=""><br class="">Go checkout my branch! &nbsp;And see the discussion there for how your proposal has impacted corelibs.<br class=""></blockquote><br class="">I’ll be happy to. &nbsp;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 &lt;<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>&gt; のメッセージ:<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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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. &nbsp;If there *is* a containing 'private' scope you can just leave the member unannotated to get this behavior. &nbsp;If there isn't you can use 'fileprivate' as it is already defined. &nbsp;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. &nbsp;A simple renaming to 'fileprivate' is what has been accepted thus far. &nbsp;<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. &nbsp;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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote></blockquote></blockquote><br class=""></blockquote></div></div></blockquote></div><br class=""></body></html>