> On 22 Feb 2017, at 08:37, Jonathan Hull <[email protected]> wrote: > > I fully agree. I actually think that applies to both solutions though. As > much as I would like to see the mess around private fixed, I think it needs > to be as part of a well considered redesign of the access system that adds > enough functionality to stop this cycle. We can’t just rename things or flip > back and forth between options every 6 months. > > As an example of what I think *is* an appropriate change is Nevin’s > suggestion on another thread to add a single level of submodules (which group > files). As part of this change, ‘private’ would mean private to the > submodule (or file if the file is not part of a submodule). > Internal/Public/Open would remain unchanged. Thus you have only private, > internal, and public/open… but the fix came as part of unifying with other > improvements (and is not just returning to pre-0025).
I saw this but it looks very confusing for me: private would mean different things in different contexts and I would have no way to make things private to a file in a submodule. > Thanks, > Jon > >> On Feb 21, 2017, at 2:41 PM, Xiaodi Wu via swift-evolution >> <[email protected]> wrote: >> >> Well-written as-is. >> >> Overall, my feedback is that solution 2 should not be on the table (though >> there are people who clamor for it), and not because I don't agree with it. >> However, simply as a matter of following an appropriate process, solution 2 >> was originally proposed in SE-0025, fully considered, and modified by the >> core team to the current design. One can disagree whether `scoped` is more >> appropriate than `private` as a name for that access modifier, and one is >> likely to say that `private` looks nicer than `fileprivate`, but that's >> neither here nor there. The appropriateness or niceness of these terms is >> unchanged from last year. Re-submitting SE-0025 cannot be the solution for >> fixing SE-0025. > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
