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

James Campbell james at supmenow.com
Tue Mar 15 18:40:42 CDT 2016

Just wondering, wouldn't private be enougth for a class level declaration ?

Not sure why we need a file baed one.


*James⎥Head of Trolls*

*james at supmenow.com <james at supmenow.com>⎥supmenow.com <http://supmenow.com>*


*Runway East *

*10 Finsbury Square*


* EC2A 1AF *

On Tue, Mar 15, 2016 at 12:18 AM, 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).
> The rationale here is that this aligns Swift with common art seen in other
> languages, and that many people using private today don’t *want* visibility
> out of their current declaration.  It also encourages “extension oriented
> programming”, at least it will when some of the other restrictions on
> extensions are lifted.  We discussed dropping the third one entirely, but
> think it *is* a useful and important level of access control, and when/if
> we ever get the ability to write unit tests inside of the file that defines
> the functionality, they will be a nicer solution to @testable.
> The thing we need to know is what the spelling should be for the third
> one.  Off hand, perhaps:
> fileprivate
> private(file)
> internal(file)
> fileaccessible
> etc
> Some other thoughts on the choice:
> - this will be a declaration modifier, so it will not “burn” a keyword.
> - if will be a uniquely Swift thing, so there is virtue in it being a
> googlable keyword.
> Thoughts appreciated.
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160315/6b01cedc/attachment.html>

More information about the swift-evolution mailing list