On Wed, Jun 15, 2016 at 1:47 PM, Matthew Johnson via swift-evolution < [email protected]> wrote:
> > > 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? > Perhaps one solution is to prohibit top-level `private` declarations? If they're required to be written as `fileprivate`, then the visibility and the modifier used to express it are once again always in sync. > > -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
