> On Jun 15, 2016, at 11:27 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> 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
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 (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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
