[swift-evolution] [Discussion] A Problem With SE-0025?

Xiaodi Wu xiaodi.wu at gmail.com
Wed Jun 29 16:19:44 CDT 2016


On Wed, Jun 29, 2016 at 4:16 PM, Matthew Johnson <matthew at anandabits.com>
wrote:

>
> On Jun 29, 2016, at 4:12 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Wed, Jun 29, 2016 at 4:07 PM, Jordan Rose <jordan_rose at apple.com>
> wrote:
>
>>
>> On Jun 29, 2016, at 14:03, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> On Wed, Jun 29, 2016 at 3:15 PM, Jordan Rose via swift-evolution <
>> swift-evolution at swift.org>wrote:
>>
>>>
>>>
>>> > On Jun 29, 2016, at 13:13, Jose Cheyo Jimenez <cheyo at masters3d.com>
>>> wrote:
>>> >
>>> > I know this might be have been brought up before but
>>> >
>>> > why not just disallow the “private" keyword for top level types,
>>> extensions etc.
>>> >
>>> > A fixit could change top level `private` to `fileprivate`.
>>> >
>>> > I think this is a little less confusing since effectively this is what
>>> is happening in the background.
>>>
>>> That doesn’t fix anything for inner types, so it’s a lot less important
>>> than the rest of the amendment.
>>>
>>> There actually is an answer to this, which is that the core team expects
>>> 'private' to be the common keyword, and therefore it’s better if you can
>>> use it at the top level and ignore ‘fileprivate’ altogether in most
>>> programs.
>>>
>>
>> On second thought, wouldn't all of this be inapplicable if `private`
>> literally meant visibility *only* within the current declaration, and
>> neither outside it nor inside any nested types, etc.?
>>
>>
>> Yes, but that's not very useful:
>>
>> public struct Foo {
>>   private var value: Int = 0
>>   public func test() {
>>     print(value) // error
>>   }
>> }
>>
>>
>> I suppose you could say that nested *types* are different from nested
>> *functions,* but then we start getting complexity in a different
>> direction. And it still doesn't fix the default access within a private
>> type.
>>
>
> Let me offer a principled rule: if I write `private var foo`, then `foo`
> is invisible at such places within the declaration where writing `private
> var bar` at the same place would cause `bar` to be visible where `foo` is
> not or vice versa.
>
>
> This violates the principle behind all of Swift’s access control rules.
> That principle is that access control is strictly based on a hierarchy of
> lexical scopes.  This is a really great principle and is what makes Swift’s
> access control better than any other I know of (IMO of course).
>

But however you slice it, some principle of Swift's access control rules is
violated by `private`. If `foo` is visible in a place where I cannot write
`private var bar` to mean the same visibility, then the access level of
`foo` is unutterable in that location, which is unprecedented as well.


>
>
>
>> Jordan
>>
>
> _______________________________________________
> 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/20160629/d7acf6aa/attachment.html>


More information about the swift-evolution mailing list