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

[Xiaodi Wu]

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.


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