> On Jun 29, 2016, at 5:17 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > > > On Wed, Jun 29, 2016 at 5:13 PM, Michael Peternell <michael.petern...@gmx.at > <mailto:michael.petern...@gmx.at>> wrote: > > > Am 29.06.2016 um 23:57 schrieb Xiaodi Wu via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: > > > > On Wed, Jun 29, 2016 at 4:46 PM, Matthew Johnson <matt...@anandabits.com > > <mailto:matt...@anandabits.com>> wrote: > > > >> On Jun 29, 2016, at 4:19 PM, Xiaodi Wu <xiaodi...@gmail.com > >> <mailto:xiaodi...@gmail.com>> wrote: > >> > >> On Wed, Jun 29, 2016 at 4:16 PM, Matthew Johnson <matt...@anandabits.com > >> <mailto:matt...@anandabits.com>> wrote: > >> > >>> On Jun 29, 2016, at 4:12 PM, Xiaodi Wu via swift-evolution > >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> > >>> On Wed, Jun 29, 2016 at 4:07 PM, Jordan Rose <jordan_r...@apple.com > >>> <mailto:jordan_r...@apple.com>> wrote: > >>> > >>>> On Jun 29, 2016, at 14:03, Xiaodi Wu <xiaodi...@gmail.com > >>>> <mailto:xiaodi...@gmail.com>> wrote: > >>>> > >>>> On Wed, Jun 29, 2016 at 3:15 PM, Jordan Rose via swift-evolution > >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>wrote: > >>>> > >>>> > >>>> > On Jun 29, 2016, at 13:13, Jose Cheyo Jimenez <ch...@masters3d.com > >>>> > <mailto:ch...@masters3d.com>> wrote: > >>>> > > >>>> > I know this might be have been brought up before but > >>>> > > >>>> > why not just disallow the “private" keyword for top level types, > >>>> > extensions etc. > >>>> > > >>>> > A fixit could change top level `private` to `fileprivate`. > >>>> > > >>>> > I think this is a little less confusing since effectively this is what > >>>> > is happening in the background. > >>>> > >>>> That doesn’t fix anything for inner types, so it’s a lot less important > >>>> than the rest of the amendment. > >>>> > >>>> There actually is an answer to this, which is that the core team expects > >>>> 'private' to be the common keyword, and therefore it’s better if you can > >>>> use it at the top level and ignore ‘fileprivate’ altogether in most > >>>> programs. > >>>> > >>>> On second thought, wouldn't all of this be inapplicable if `private` > >>>> literally meant visibility *only* within the current declaration, and > >>>> neither outside it nor inside any nested types, etc.? > >>> > >>> Yes, but that's not very useful: > >>> > >>> public struct Foo { > >>> private var value: Int = 0 > >>> public func test() { > >>> print(value) // error > >>> } > >>> } > >>> > >>> I suppose you could say that nested types are different from nested > >>> functions, but then we start getting complexity in a different direction. > >>> And it still doesn't fix the default access within a private type. > >>> > >>> Let me offer a principled rule: if I write `private var foo`, then `foo` > >>> is invisible at such places within the declaration where writing `private > >>> var bar` at the same place would cause `bar` to be visible where `foo` is > >>> not or vice versa. > >> > >> This violates the principle behind all of Swift’s access control rules. > >> That principle is that access control is strictly based on a hierarchy of > >> lexical scopes. This is a really great principle and is what makes > >> Swift’s access control better than any other I know of (IMO of course). > >> > >> But however you slice it, some principle of Swift's access control rules > >> is violated by `private`. If `foo` is visible in a place where I cannot > >> write `private var bar` to mean the same visibility, then the access level > >> of `foo` is unutterable in that location, which is unprecedented as well. > > > > I don’t think utterability was a conscious principle to the degree that > > scope based access control was. If that was the case the issue would > > surely have been identified during review. It wasn’t until Robert started > > the implementation that anyone (AFAIK) notices that the proposal introduces > > unutterable visibility in some cases. Utterability just isn’t something > > people were thinking about until then. > > > > But you are right that unutterability is unprecedented and I think everyone > > agrees that it poses problems which is why Jordan and Robert have amended > > the proposal to make the visibility members of private types without > > explicit access control utterable. > > > > The solution we want is to preserve *both* of these principles, not change > > which one were violating. :) > > > > If a private member must be visible within a nested type, then that access > > level necessarily becomes unutterable within the nested type unless we > > introduce another keyword, which is out of scope without a new proposal. > > There is no squaring the circle to be had. The amendment, to my > > understanding, simply hacks around this issue to make `private` nonetheless > > useful by allowing `fileprivate` things inside `private` things, but in so > > doing we're enshrining which of these principles we're violating, not > > finding a solution that avoids violating them. > > So, the problem is that there are access levels that cannot be specified > explicitly? We can either accept that or reject the proposal completely. Or > am I missing something? Are there any other solutions that are even worth > considering? > > I don't see a problem with unutterable access levels. I also don't see a > problem with unprecedented unutterable access levels. In Swift 2 all access > levels where utterable. In Swift 3 we lose that ability. Is the loss > significant? Maybe it's hard to implement into the compiler, I don't know, > but as a language user its easy to understand what is going on IMO. > > 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` > } > } > ```
This is *not* true of the semantics intended by SE-0025 and provided by Jordan’s amendment. `Bar` is visible everywhere `Foo` is visible and so are the members of `Bar` that do not have explicit access control. > > > -Michael > > > > > > >> > >> > >>> > >>> Jordan > >>> > >>> _______________________________________________ > >>> swift-evolution mailing list > >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> > >>> https://lists.swift.org/mailman/listinfo/swift-evolution > >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > >> > >> > > > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
