[swift-evolution] final + lazy + fileprivate modifiers

Brent Royal-Gordon brent at architechies.com
Fri Feb 17 16:29:57 CST 2017

> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution <swift-evolution at swift.org> 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.

Brent Royal-Gordon

More information about the swift-evolution mailing list