How about this, it might make more sense and relax the behavior a little:
// 1. file scope (Level 0)
// Level 0 because its declared at file scope
private struct A {
/* implicit private */ init() {} // Level 1
}
// Level 0
struct B {
// `A` is visible here and is seen as `fileprivate` because it is accessed
// from a level >= itself (imagine something like a "scope level tree").
// also every member of `A` are interpreted as
// `fileprivate` and everyting is visible again as intended
var a: A = A()
}
// 2. file scope (Level 0)
struct C {
// `A` is not visible here
// `B` is visible because its `internal` by default
}
Does this makes sense to you?
___________
| file Root |
|___________|
|______________________
__|_________________ __|_________________________
| struct B (Level 0) | | private struct A (Level 0) |
|____________________| |____________________________|
| |
__|______________ _____|____________________
| var a (Level 1) | | private init() (Level 1) |
|_________________| |__________________________|
To check if `a` has visibility to `init` of `A` we need to compare the
visibility level of `B` against `A`. If it is equal than `private` is
handled as `fileprivate` which means that any other member from within
the scope of `A` are also handled as `fileprivate`. We've get the same result
if `B`s level is greater than `A`s. That means that we'll get back the
visibility by relaxing `private` in some cases as `fileprivate`.
The described behavior is the same for private on higher levels, but we don’t
describe it as fileprivate there (or can we do that?):
extension B {
private func foo() {
// `boo` should be visible here
}
private func boo() {
// `foo` should be visible here
}
}
--
Adrian Zubarev
Sent with Airmail
Am 15. Juni 2016 um 20:53:21, Robert Widmann via swift-evolution
([email protected]) schrieb:
Then it is no different from fileprivate.
~Robert Widmann
2016/06/15 11:47、Matthew Johnson <[email protected]> のメッセージ:
>
>> On Jun 15, 2016, at 1:37 PM, Robert Widmann <[email protected]> wrote:
>>
>> The scope of the *declaration* is not the issue. The scope of its *members*
>> is.
>
> Let’s consider an example:
>
> private struct Foo {
> var bar: Int
> }
>
> // elsewhere in the same file:
> var foo = Foo(bar: 42)
> foo.bar = 44
>
> `Foo` is declared private. Private for this declaration is at the file scope.
> The `bar` member has no access modifier so it has the same visibility as the
> struct itself, which is file scope. This will also be true of the implicitly
> synthesized memberwise initializer.
>
> This means that it is possible to initialize `foo` with a newly constructed
> instance of `Foo` and to modify the `bar` member anywhere else in the same
> file.
>
> If `bar` was also declared `private` this would not be possible as its
> visibility would be restricted to the surrounding scope of the initial
> declaration of `Foo`. This means `Foo` would need to provide an explicit
> initializer or factory method with `fileprivate` visibility in order to be
> usable.
>
> Members with no explicit access modifier should have the same *visibility* as
> their containing type (with a maximum implicit visibility of internal), not
> the same *modifier* as their containing type. The only case where there is a
> distinction is the new `private` visibility. Maybe that is what is causing
> the confusion?
>
> Does this help?
>
> -Matthew
>
>>
>> ~Robert Widmann
>>
>> 2016/06/15 11:36、Matthew Johnson <[email protected]> のメッセージ:
>>
>>> The scope for a top-level declaration is the file itself. This means that
>>> top-level declarations with `private` and `fileprivate` should have the
>>> same behavior. They should not be uninstantiable or unusable.
>>>
>>> -Matthew
>>>
>>>> On Jun 15, 2016, at 1:31 PM, Robert Widmann via swift-evolution
>>>> <[email protected]> wrote:
>>>>
>>>> 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
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
