Then it is no different from fileprivate.
~Robert Widmann
2016/06/15 11:47、Matthew Johnson <matt...@anandabits.com> のメッセージ:
>
>> 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
