[swift-evolution] Analysis of existing scopes

[Xiaodi Wu]

On Fri, Feb 24, 2017 at 3:32 AM, Joanna Carter via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > Le 23 févr. 2017 à 20:48, Matthew Johnson <matthew at anandabits.com> a
> écrit :
> >
> > Sometimes APIs are used internally in production while eventually
> planned for public visibility.  New features in Apple’s frameworks often
> start life this way.
>
> Hmmm. In my experience, if I wanted to experiment with something in the
> context of the whole project, I would tend to create a branch of the
> project in source control, experiment and either merge the branch if
> successful or delete it if not.
>
> > I don’t have a strong feeling about this particular capability.  I’m
> just trying to state the rationale as I understand it.
>
> Pease don't think I am criticising your understanding, it's just that such
> a rationale doesn't seem very, well, rational :-)


It is a useful generalization of an absolutely obligatory feature for new
`private`. Consider the following:

```
private class Foo {
  private class Bar {
    /* blank */ class Baz { }
  }
}
```

What access modifier can be used in place of `blank` to make `Foo.Bar.Baz`
have the same visibility as `Foo.Bar`? Note that `private` inside the type
is more restrictive than `private` in the declaration of the type; the
precise visibility of `Foo.Bar` is not expressible inside `Foo.Bar` itself.
To allow `Foo.Bar.Baz` to be visible everywhere that `Foo.Bar` is visible,
we must allow `blank` to be replaced by a modifier other than `private`.



> --
> Joanna Carter
> Carter Consulting
>
> _______________________________________________
> 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/20170224/99af595e/attachment.html>