> On Jun 15, 2016, at 4:27 PM, Xiaodi Wu <[email protected]> wrote: > > On Wed, Jun 15, 2016 at 4:14 PM, Matthew Johnson <[email protected] > <mailto:[email protected]>> wrote: > >> On Jun 15, 2016, at 4:08 PM, Xiaodi Wu <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Wed, Jun 15, 2016 at 3:09 PM, Matthew Johnson <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On Jun 15, 2016, at 2:55 PM, Xiaodi Wu <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On Wed, Jun 15, 2016 at 2:48 PM, Matthew Johnson via swift-evolution >>> <[email protected] <mailto:[email protected]>>wrote: >>> >>>> On Jun 15, 2016, at 2:46 PM, Adrian Zubarev via swift-evolution >>>> <[email protected] <mailto:[email protected]>> 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. :) > > >> >> -Matthew >>>> >>>> >>>> >>>> -- >>>> Adrian Zubarev >>>> Sent with Airmail >>>> >>>> Am 15. Juni 2016 um 21:40:37, Matthew Johnson ([email protected] >>>> <mailto:[email protected]>) 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 >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
