[swift-evolution] [Review] SE-0159: Fix Private Access Levels

Nevin Brackett-Rozinsky nevin.brackettrozinsky at gmail.com
Mon Mar 27 13:15:29 CDT 2017


On Mon, Mar 27, 2017 at 1:47 PM, Charles Srstka via swift-evolution <
swift-evolution at swift.org> wrote:

> On Mar 27, 2017, at 12:00 PM, Ross O'Brien via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> <snip>
>
>
> Creates a mechanism that actually makes sense for what people are using
> ‘extension’ for, solves the scoping problems, eliminates the need for
> fileprivate, solves all the problems that people are complaining about.
>

No it does not.

In addition to the protocol-conformance pattern that Ross describes, people
also use extensions to let types declared elsewhere (even in another
module!) work with types declared locally. So in Foo.swift we will have the
implementation of Foo, as well as things like “extension String { /*
Foo-related stuff */ }”.

The file-scope access level, which had been and should be spelled
“private”, enables those extensions of external types to access
implementation details of Foo to do their work. Thus Ross’s scheme does not
eliminate the need for file-level visibility at all. In my view, what we
really need is an access level *broader* than a single file, so that
implementation details can be made visible across a select group of
tightly-related files but not the rest of the module. However that is out
of scope for Swift 4.

Nevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170327/46dba6fa/attachment.html>


More information about the swift-evolution mailing list