<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>That is for migration. It does not affect the semantics of private at any level, it merely explains how we should go about the initial transition. "In many cases" private being equivalent to fileprivate could be read that way, but given the rest of the proposal I didn't take any artistic freedoms and don't believe we should without clarification. <br><br>~Robert Widmann</div><div><br>2016/06/16 2:00、Jonathan Hull <<a href="mailto:jhull@gbis.com">jhull@gbis.com</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">From the Impact portion of the proposal:<div class=""><blockquote type="cite" class=""><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">The existing code will need to rename </span><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; color: rgb(51, 51, 51);" class="">private</code><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""> to </span><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; color: rgb(51, 51, 51);" class="">fileprivate</code><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""> to achieve the same semantics. In many cases the new meaning of </span><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; color: rgb(51, 51, 51);" class="">private</code><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""> is likely to compile as well and the code will then run exactly as before.</span></blockquote><br class=""></div><div class="">I believe the second sentence refers to the case where fileprivate and private are the same at the top level. I agree that the proposal is a bit vaguely/ambiguously written, but it in no way precludes the behavior everyone is saying was intended.</div><div class=""><br class=""></div><div class="">I know the current implementation just gives unannotated members the same access modifier as the outer scope’s, but that is an implementation detail. Furthermore it is entirely consistent with the interpretation given above in the case with only “fileprivate”, “internal”, and “public” scopes. It is only when we add the new “private” scope that there is a difference.</div><div class=""><br class=""></div><div class="">We have an ambiguous proposal which can be read in two different ways, but one of those ways is unworkable (the bug you mentioned), so I see no problem in interpreting it the other way (which just so happens to be the interpretation everyone says was intended) and moving forward. It is entirely consistent with the proposal.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 16, 2016, at 12:35 AM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:</div><div class=""><div class="">~Robert Widmann<br class=""><br class="">2016/06/16 0:29、Jonathan Hull <<a href="mailto:jhull@gbis.com" class="">jhull@gbis.com</a>> のメッセージ:<br class=""><br class=""><blockquote type="cite" class="">They happen to be the same at the top level, but they are very different when dealing with nested types…<br class=""><br class="">A private member is visible inside it’s containing scope. For the top-level, that is the file. For a nested type, that is the outer type.<br class=""></blockquote><br class="">A wonderful idea, but not in the proposal. In fact, the singular example given therein runs directly counter to this idea by explicitly showing the scoping behavior of a private member.<br class=""></div></div></blockquote><div><br class=""></div><div>Chis Lattner’s response to the initial proposal (before the name fileprivate was chosen):</div><div><blockquote type="cite" class=""><span style="font-family: arial, sans-serif; background-color: rgb(255, 255, 255);" class="">Per Doug’s email, the core team agrees we should make a change here, but would like some bikeshedding to happen on the replacement name for private.</span><br style="font-family: arial, sans-serif;" class=""><br style="font-family: arial, sans-serif;" class=""><span style="font-family: arial, sans-serif; background-color: rgb(255, 255, 255);" class="">To summarize the place we’d like to end up:</span><br style="font-family: arial, sans-serif;" class=""><br style="font-family: arial, sans-serif;" class=""><span style="font-family: arial, sans-serif; background-color: rgb(255, 255, 255);" class="">- “public” -> symbol visible outside the current module.</span><br style="font-family: arial, sans-serif;" class=""><span style="font-family: arial, sans-serif; background-color: rgb(255, 255, 255);" class="">- “internal” -> symbol visible within the current module.</span><br style="font-family: arial, sans-serif;" class=""><span style="font-family: arial, sans-serif; background-color: rgb(255, 255, 255);" class="">- unknown -> symbol visible within the current file.</span><br style="font-family: arial, sans-serif;" class=""><span style="font-family: arial, sans-serif; background-color: rgb(255, 255, 255);" class="">- “private” -> symbol visible within the current declaration (class, extension, etc).</span><br style="font-family: arial, sans-serif;" class=""><br style="font-family: arial, sans-serif;" class=""><span style="font-family: arial, sans-serif; background-color: rgb(255, 255, 255);" class="">The rationale here is that this aligns Swift with common art seen in other languages, and that many people using private today don’t *want* visibility out of their current declaration. It also encourages “extension oriented programming”, at least it will when some of the other restrictions on extensions are lifted. We discussed dropping the third one entirely, but think it *is* a useful and important level of access control, and when/if we ever get the ability to write unit tests inside of the file that defines the functionality, they will be a nicer solution to <at> testable.</span></blockquote><br class=""></div><div>As you can see the definition of “unknown” (now fileprivate) and “private” are exactly what I said. Many people wanted to name the new private “scoped” or “local" because of the way it worked, though “private” won in the end. As you see, they thought of getting rid of fileprivate, but decided it was necessary.</div><div><br class=""></div><div><br class=""></div><div><blockquote type="cite" class="">Then we should amend the proposal posthaste!</blockquote></div><div><br class=""></div><div>Basically, what I am saying here is that the intent is clear from the context (and original discussion) around the proposal. We all seem to agree about what needs to happen behavior-wise. At most this is a bug-fix, and shouldn’t require a full rehashing on evolution.</div><div><br class=""></div><div>Thanks,</div><div>Jon</div><div><br class=""></div><div><br class=""></div></div></div></div></blockquote></body></html>