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

[Ilya Belenkiy]

After today's discussion, I changed the proposal back to only describe the
new names (fileprivate etc.)  and keep the lexical scope (I still want the
immediate scope, but after Jordan's explanation that it's not standard and
that other major languages don't do this, I decided to remove it.)
https://github.com/apple/swift-evolution/pull/235
(I am not a git expert, so I created a new pull request)

On Sun, Mar 27, 2016 at 10:03 PM Ilya Belenkiy via swift-evolution <
swift-evolution at swift.org> wrote:

> I created a pull request with the updated proposal:
> https://github.com/apple/swift-evolution/pull/234
>
> On Mon, Mar 14, 2016 at 8: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).
>>
>> 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
>>
> _______________________________________________
> 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/20160329/5c0de78f/attachment.html>