On Wed, Jun 15, 2016 at 4:30 PM, Matthew Johnson <matt...@anandabits.com> wrote:
> > On Jun 15, 2016, at 4:27 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Wed, Jun 15, 2016 at 4:14 PM, Matthew Johnson <matt...@anandabits.com> > wrote: > >> >> On Jun 15, 2016, at 4:08 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >> >> On Wed, Jun 15, 2016 at 3:09 PM, Matthew Johnson <matt...@anandabits.com> >> wrote: >> >>> >>> On Jun 15, 2016, at 2:55 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>> >>> On Wed, Jun 15, 2016 at 2:48 PM, Matthew Johnson via swift-evolution < >>> swift-evolution@swift.org>wrote: >>> >>>> >>>> On Jun 15, 2016, at 2:46 PM, Adrian Zubarev via swift-evolution < >>>> swift-evolution@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 (matt...@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@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
