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
