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