> On Feb 12, 2017, at 10:14 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > FWIW, you're not the first to propose these names. `public(open)` was > suggested during the `open` debate and rejected in favor of `open`. > `private(file)` was suggested during the `fileprivate` debate and rejected in > favor of `fileprivate`. `protected` and `abstract` have been suggested on > this list multiple times.
Yes, these proposals are not going to happen IMO. I don’t speak for the core team, but we should be aiming to *reduce* complexity in the access control space (even at the cost of expressivity) — not increase it. -Chris > > > On Mon, Feb 13, 2017 at 12:04 AM, Vanderlei Martinelli via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Some corrections and additions to my previous email: > > public(open) // if open is absent, the method is “closed” > protected // (yes, we and Cocoa still use classes) > internal > private(file) // if file is absent, the method is really, really private > > And one observation: protected and abstract as described before: only to be > valid for classes, of course. Something like local access modifier for local > only scope would be nice too (and does not break anything written until > today). > > — > Vanderlei Martinelli > > _______________________________________________ > 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
