> On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution >> <[email protected]> wrote: >> >> Personally I feel enforced encapsulation of implementation detail to the >> latter group is less important than the former, and can be handled by >> convention. Whereas other users of your module definitely benefit from >> access control and being able to consume a clearly-defined interface. > > I think failing to provide some sort of below-`internal` privacy would be > missing *really* low-hanging fruit for no good reason. The languages I can > think of which don't include some sort of sub-library-wide privacy > level—Objective-C, Javascript, Perl, Python—usually have very simple object > designs with a flat namespace. (Well, there's Rust, but Rust lets you wrap > anything you'd like in a module.) Even Objective-C in practice includes a > `fileprivate` equivalent in the form of methods declared only in the .m file. > > I also think it's often helpful to be able to change a member's access level > without having to change all references to it. Publishing or privatizing an > interface is not an uncommon refactoring. > > Not everybody likes our current semantics, but that's no reason to throw the > feature out entirely.
+1. I’d like to see `private` revert to the Swift 2 meaning, and hopefully we can reconsider using `scoped` as the keyword for scoped access rather than abandoning it. Does anyone remember why this was considered a bad idea? > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
