~Robert Widmann
2016/06/16 0:29、Jonathan Hull <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.
>
> You may, for instance have an outer type which is marked Internal or public,
> but an inner type which is marked fileprivate so that extensions in the file
> can use the inner type. That is different than marking the inner type
> private, which would only allow access inside the outer type, but not in
> extensions.
That is defined behavior. The inner private type's members are, however, still
private and cannot escalate their access beyond that.
>
> Again, I want to point out that the behavior I described in my earlier
> message is the only plausible/usable behavior because we have no other way to
> specify that a member should have the same visibility as it’s enclosing
> scope… which is a common and important use-case. Doing it your way, as you
> point out in your original message, leads to the problem of having no way to
> instantiate types marked private.
Then we should amend the proposal posthaste!
>
> This was all thoroughly discussed during the proposal process, with lots of
> people talking about the fact that private & fileprivate are the same at the
> top level… and the response was that, yes, this is by design. In most cases
> you can continue to just use the shorter private, and you only need to bring
> in fileprivate for nested types. Fileprivate is one of those things that you
> REALLY need when you need it though, which is why it was included.
Good to know I'm not the only one with reservations.
>
> Thanks,
> Jon
>
>
>> On Jun 16, 2016, at 12:06 AM, Robert Widmann <devteam.cod...@gmail.com>
>> wrote:
>>
>> But the proposal does not specify that and that is not how swift's access
>> control mechanisms currently work, unfortunately. A private aggregate must
>> have private members, and those members are subject to private access
>> whether annotated or not.
>>
>> On top of that, you break containment this way. A private member is not
>> supposed to be visible outside of its current declaration. An aggregate
>> full of private members similarly. You can see the aggregate, but you
>> cannot see its members. If we relax this, then private is no different from
>> fileprivate and we should just stick to our current tri-valued access
>> control system.
>>
>> ~Robert Widmann
>>
>> 2016/06/15 23:04、Jonathan Hull via swift-evolution
>> <swift-evolution@swift.org> のメッセージ:
>>
>>> My understanding of the proposal was that the unannotated
>>> properties/methods inside of a scope have the same *visibility* as their
>>> surrounding scope, or internal, whichever is less.
>>>
>>> That is slightly different than having the same access level. Thus:
>>>
>>> private struct Outer {
>>> var inner:Int
>>> }
>>>
>>> is different than:
>>>
>>> private struct Outer {
>>> private var inner:Int
>>> }
>>>
>>> In the first, inner is accessible precisely everywhere where Outer is
>>> accessible. In the second, inner is only accessible within Outer itself.
>>> It is important that we have the first behavior for unannotated inner,
>>> because there is no other way to spell it.
>>>
>>> That is my understanding of the intent of SE-0025, even if the exact
>>> wording is confusing.
>>>
>>> Thanks,
>>> Jon
>>>
>>> P.S. I would personally like to see unannotated properties/methods inside
>>> of a scope have the same visibility as their surrounding scope. Full stop.
>>> End of sentence. (It seems to me like the special handling of internal is
>>> what is causing the confusion here). That is what I would expect the
>>> behavior to be if I didn’t know. That isn’t what was written in the
>>> proposal though...
>>>
>>>> While implementing SE-0025 (fileprivate), I noticed an interesting bug in
>>>> the proposal. Under the implementation outlined there, any top-level
>>>> structure, class, or enum declared private cannot possibly be instantiated
>>>> and so cannot be used in any way. Because of this, private top-level
>>>> declarations are more often than not blown away entirely by the compiler
>>>> for being unused. It seems strange to me to allow a key language feature
>>>> to act solely as a hint to the optimizer to reduce the size of your
>>>> binary. Perhaps the restrictions around private needs to be relaxed or
>>>> the line between fileprivate and private needs to be investigated again by
>>>> the community before inclusion in the language.
>>>>
>>>> Thoughts?
>>>>
>>>> ~Robert Widmann
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
