[swift-evolution] [Discussion] A Problem With SE-0025?

[Jonathan Hull]

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.codafi at 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 <jhull at gbis.com <mailto:jhull at 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.codafi at gmail.com <mailto:devteam.codafi at gmail.com>> wrote:
>>> ~Robert Widmann
>>> 
>>> 2016/06/16 0:29、Jonathan Hull <jhull at gbis.com <mailto:jhull at 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
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160616/ca776b39/attachment.html>