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

[Xiaodi Wu]

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

>
> On Jun 29, 2016, at 4:19 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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.
>
>
> I don’t think utterability was a conscious principle to the degree that
> scope based access control was.  If that was the case the issue would
> surely have been identified during review.  It wasn’t until Robert started
> the implementation that anyone (AFAIK) notices that the proposal introduces
> unutterable visibility in some cases.  Utterability just isn’t something
> people were thinking about until then.
>
> But you are right that unutterability is unprecedented and I think
> everyone agrees that it poses problems which is why Jordan and Robert have
> amended the proposal to make the visibility members of private types
> without explicit access control utterable.
>
> The solution we want is to preserve *both* of these principles, not change
> which one were violating. :)
>

If a private member must be visible within a nested type, then that access
level necessarily becomes unutterable within the nested type unless we
introduce another keyword, which is out of scope without a new proposal.
There is no squaring the circle to be had. The amendment, to my
understanding, simply hacks around this issue to make `private` nonetheless
useful by allowing `fileprivate` things inside `private` things, but in so
doing we're enshrining which of these principles we're violating, not
finding a solution that avoids violating them.


>
>
>
>>
>>
>>
>>> 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/6cd68cb6/attachment.html>