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

[Xiaodi Wu]

On Wed, 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.
>
>

Humble suggestion: if `private` were left unimplemented with respect to
types, all motivating reasons and examples given in SE-0025 could still be
delivered for Swift 3. A follow-on proposal could tackle these challenges
explicitly rather than amending an existing proposal without re-review. Any
such changes could be punted until after Swift 3 because they would be
strictly additive.

> 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/1cda507d/attachment.html>