[swift-evolution] SE-0025: Scoped Access Level, next steps

Shawn Erickson shawnce at gmail.com
Mon Mar 14 19:45:21 CDT 2016

On Mon, Mar 14, 2016 at 5:18 PM Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> Per Doug’s email, the core team agrees we should make a change here, but
> would like some bikeshedding to happen on the replacement name for private.
> To summarize the place we’d like to end up:
> - “public” -> symbol visible outside the current module.
> - “internal” -> symbol visible within the current module.
> - unknown -> symbol visible within the current file.
> - “private” -> symbol visible within the current declaration (class,
> extension, etc).

Very much like the thinking.

I guess it isn't feasible at this point to change `internal` to mean file
scoped? That could avoid the need for another qualifier by simply
leveraging the default of module scope for things without an access

As you know the default of whole module means most developers need never
use access control unless they desire to reduce access scope (e.g. file
scope, dec scoped). Those working on frameworks would be the ones to
leverage public in addition to the other levels.

Of the top of my head: ` pubic`, `internal` (and `internal(module`)),
`internal(file)`, `private`. This makes public and private being closest to
other languages as you noted with internal being more swift nuanced.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160315/f79a4263/attachment.html>

More information about the swift-evolution mailing list