[swift-evolution] [Discussion] A Problem With SE-0025?

[Xiaodi Wu]

On Wed, Jun 15, 2016 at 1:47 PM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Jun 15, 2016, at 1:37 PM, Robert Widmann <devteam.codafi at 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?
>

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 <matthew at 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 at 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 at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160615/0334de0e/attachment.html>