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

[L. Mihalkovic]

> On Jun 15, 2016, at 11:27 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> 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

Would be interesting to hear the core team on the topic of sub modules, considering how deep the implications would run to open that door (potential compatibility breaking change to the structure of the dylibs). Would be wise for them to say a quick possible/not-in-this-lifetime before people (including me) start to dream too much about them.

> could serve your use case without `fileprivate`. That, IMO, would be a logical endpoint of moving from file-based access to scope-based access.
> 
>> 
>>>  
>>>> -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
>> 
> 
> _______________________________________________
> 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/20160616/e1a33fd1/attachment.html>