Ok, I guess we will wait for the core team (or perhaps Ilya) to return and advise then…
Thanks, Jon > On Jun 16, 2016, at 7:33 AM, Robert Widmann <devteam.cod...@gmail.com> wrote: > > 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. > > ~Robert Widmann > > 2016/06/16 2:00、Jonathan Hull <jh...@gbis.com <mailto:jh...@gbis.com>> のメッセージ: > >> From the Impact portion of the proposal: >>> The existing code will need to rename private to fileprivate to achieve the >>> same semantics. In many cases the new meaning of private is likely to >>> compile as well and the code will then run exactly as before. >> >> 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. >> >> 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. >> >> 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. >> >> >> >>> On Jun 16, 2016, at 12:35 AM, Robert Widmann <devteam.cod...@gmail.com >>> <mailto:devteam.cod...@gmail.com>> wrote: >>> ~Robert Widmann >>> >>> 2016/06/16 0:29、Jonathan Hull <jh...@gbis.com <mailto:jh...@gbis.com>> >>> のメッセージ: >>> >>>> They happen to be the same at the top level, but they are very different >>>> when dealing with nested types… >>>> >>>> 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. >>> >>> 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. >> >> Chis Lattner’s response to the initial proposal (before the name fileprivate >> was chosen): >>> 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. >>> >>> To summarize the place we’d like to end up: >>> >>> - “public” -> symbol visible outside the current module. >>> - “internal” -> symbol visible within the current module. >>> - unknown -> symbol visible within the current file. >>> - “private” -> symbol visible within the current declaration (class, >>> extension, etc). >>> >>> 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. >> >> 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. >> >> >>> Then we should amend the proposal posthaste! >> >> >> 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. >> >> Thanks, >> Jon >> >>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
