> On Jun 15, 2016, at 1:37 PM, Robert Widmann <devteam.cod...@gmail.com> 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 <matt...@anandabits.com> のメッセージ:
>
>> 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
>>> <swift-evolution@swift.org> 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
>>> 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
