[swift-evolution] final + lazy + fileprivate modifiers

David Waite david at alkaline-solutions.com
Mon Feb 20 22:21:47 CST 2017

> On Feb 20, 2017, at 10:04 AM, Joanna Carter via swift-evolution <swift-evolution at swift.org> wrote:
> Otherwise known in my language as :
> public - anywhere
> internal - anywhere inside the module
> private - only inside current type
> extensible - in current file and in subtypes/extensions in other files
> The only other option that might be useful is something like 'internal extensible' to limit visibility for extensible members to the current module.
If a type is extensible by other modules at all, I prefer that to be spelled “public”.

> Sorry, I would still like to see a waterproof argument for what is presently called fileprivate ; with the above scopes, I simply can't see the need. Unless you can convince me, that is ;-)

 In C++ terms, it would be when I want some other class to have friend access to a function/data, but for it not to be arbitrarily accessible by subtypes

I believe the critical piece of designing access levels is for the levels to document the intent of the developer specifying the access level. Does “extensible” indicate that the designer of the library wanted a certain kind of access - or that the compiler maybe gave an error at some point when it was “private”?


More information about the swift-evolution mailing list