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

[Xiaodi Wu]

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

>
> On Jun 15, 2016, at 4:27 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Wed, Jun 15, 2016 at 4:14 PM, Matthew Johnson <matthew at anandabits.com>
> wrote:
>
>>
>> On Jun 15, 2016, at 4:08 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> On Wed, Jun 15, 2016 at 3:09 PM, Matthew Johnson <matthew at anandabits.com>
>>  wrote:
>>
>>>
>>> On Jun 15, 2016, at 2:55 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>> On Wed, Jun 15, 2016 at 2:48 PM, Matthew Johnson via swift-evolution <
>>> swift-evolution at swift.org>wrote:
>>>
>>>>
>>>> On Jun 15, 2016, at 2:46 PM, Adrian Zubarev via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>> I was referencing to the issue Robert discovered in his implementation.
>>>>
>>>>
>>>> I do understand what the proposal is all about, but thank you for
>>>> re-clarifying that to me. :)
>>>>
>>>>
>>>> I don’t think it’s a bug, but it is definitely something that isn’t as
>>>> clear as it should have been.
>>>>
>>>
>>> Was it intentional on the part of the proposal, then, that there should
>>> be two modifiers meaning the same thing for a top level declaration in a
>>> file? Or was it intended that only one or the other be used in that
>>> scenario?
>>>
>>>
>>> I don’t think it was carefully considered, although I think it did come
>>> up at some point during discussion in the context of compatibility with
>>> existing code (i.e. nothing changes for current top-level `private`
>>> declarations).
>>>
>>> It is in some sense a “coincidence” that they mean the same thing at
>>> file scope.  The proposal would have had to introduce a specific
>>> prohibition to prevent this situation and it did not do so.  That said, I
>>> think this kind of issue falls well within the discretion of the core team
>>> to make a call without violating the spirit of the proposal.
>>>
>>> There are two reasonable options here:
>>>
>>> 1. Allow both `private` and `fileprivate` at file scope despite the fact
>>> that they have the same meaning.  This is more consistent in the sense that
>>> we are not introducing a special case that arbitrarily prohibits an
>>> otherwise valid access modifier.  It also means that nothing needs to
>>> change for top level `private` declarations in existing code.
>>>
>>> 2. Prohibit `private` at file scope.  Given that it appears as if the
>>> behavior of `private` at file scope may not be intuitive and is equivalent
>>> to `fileprivate` it might be reasonable to just disallow it.  This would
>>> result in more consistent *code* (even if there needs to be a special case
>>> in the language).
>>>
>>> I don’t have a strong opinion on which option we choose.  But I do feel
>>> strongly that the semantics of `private` need to properly respect the scope
>>> in which the keyword is written and into which the associated declaration
>>> is introduced (rather than the scope *inside* the declaration it is
>>> attached to).
>>>
>>
>> Right, I think both would be OK. More radically, we might want to
>> re-evaluate the continued utility of a `fileprivate` scope. It seems the
>> use cases for such a scope not adequately served by either `internal` or
>> the new `private` would be exceedingly rare.
>>
>>
>> I disagree with that.  `fileprivate` is indispensable when you need it.
>> There are times when you want to keep visibility limited to the current
>> file but the new `private` is too restrictive (for example, you need to
>> access a member of one type in a closely related extension of a different
>> type that lives in the same file).
>>
>
> Sure. This was more of a thought for the future. As we move towards fully
> embracing a scope-based model for organizing code, modules will no longer
> need to be strictly "single units of code distribution," and a move towards
> supporting submodules could serve your use case without `fileprivate`.
> That, IMO, would be a logical endpoint of moving from file-based access to
> scope-based access.
>
>
> I would really like to see submodules, but I think there would still be
> valid uses for `fileprivate` even with them.  But of course we would need
> to know the details of submodules to have a good discussion about that so
> it’s a topic for the future. :)
>

I wonder what became of this:
https://github.com/apple/swift/blob/master/docs/Modules.rst#id18

>
>> -Matthew
>>>
>>>
>>>>
>>>>
>>>> --
>>>> Adrian Zubarev
>>>> Sent with Airmail
>>>>
>>>> Am 15. Juni 2016 um 21:40:37, Matthew Johnson (matthew at anandabits.com)
>>>> schrieb:
>>>>
>>>> What seems like a nasty bug missed during review?  I don’t follow you
>>>> there.
>>>>
>>>> This proposal was specifically designed to follow Swift’s design of a
>>>> scope-based access control mechanism rather than a type-based access
>>>> control mechanism that is common in other languages.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20160615/d6346834/attachment.html>