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

[Xiaodi Wu]

On Wed, Jun 29, 2016 at 5:41 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Wed, Jun 29, 2016 at 5:36 PM, Matthew Johnson <matthew at anandabits.com>
> wrote:
>
>>
>> On Jun 29, 2016, at 4:57 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> 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.
>>
>>
>> Do you mean a third principle which says something like “a member shall
>> not have a higher access level than its parent”.  If so, you are correct
>> that Jordan’s amendment does violate that and another proposal would be
>> necessary to give it a name that does not exist today.  I don’ think that's
>> going to happen for Swift 3.
>>
>
> No, not exactly what I mean, but that is a concern. Jordan's proposal
> introduces a dichotomy between the actual access level (i.e. the answer to
> the question, which code can see this member?) and the access modifier
> which is used in conjunction with the member (which would become
> `fileprivate`). So yes, I can utter something, but it doesn't change the
> fact that the question "which code can actually see this member?" still has
> no utterable answer.
>


!!!
This just hit me like a ton of bricks. Jordan's proposal is repurposing
`fileprivate` to mean this previously unutterable scope and divorcing it
from meaning "private to file".


>
>> 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/833a8a06/attachment.html>