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

[Xiaodi Wu]

On Wed, Jun 29, 2016 at 5:33 PM, Michael Peternell via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > Am 30.06.2016 um 00:17 schrieb Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org>:
> >
> > Here is the problem:
> >
> > ```
> > private struct Foo {
> >   /* private */ struct Bar {
> >     // it doesn't matter what you write in here, you'll never see it in
> `Foo`
> >   }
> > }
> > ```
> >
>
> So this is not a practical design for this feature then. Following the
> ideas I presented a few hours earlier this should lead to:
>
> private struct Foo {
>     struct Bar {
>         var strawberryBar: [String]
>     }
>     // Scope(Bar) = Scope(Foo), because the scope of Bar is unspecified
>     // Scope(Bar.strawBerryBar) = Scope(Bar) = Scope(Foo), for the same
> reason
>     // Foo is visible here => Bar.strawberryBar is visible too
>
>     func hello() {
>         let s = Bar(strawberryBar: ["yummi"]
>         print("mjam: \(s.strawberryBar)")
>     }
>     // everything compiles...
> }
>
> Making Bar implicitly private doesn't make sense at all. Bar should have
> the same scope as Foo. `private` on Bar has a completely different meaning
> than `private` on Foo so this is not the same access level. The implicit
> access level of Bar is unutterable here.
>
> Anyways... I'm out. I think there *is* a possible design that works. As
> long as no one provides another (possibly better) solution or argues with
> my why my design can not work I see no point (for me) in continuing this
> discussion.
>

Yes, I think that would work; but it sounds like the core team has rejected
this suggestion, so I'm suggesting others.


>
> -Michael
>
> _______________________________________________
> 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/20160629/30ad6f1b/attachment.html>