> On Apr 7, 2017, at 9:48 AM, David Hart via swift-evolution > <[email protected]> wrote: > >> >> On 7 Apr 2017, at 15:41, BJ Homer via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> -0.5 >> >> SE-0159 was rejected because it was determined that some developers are >> actively using strongly-scoped access control. This proposal removes that >> strong scoping, so I do not see how we can reasonably reject that proposal >> but accept this one. > > I don’t know what you mean by strong in strong-scoped access, but your > statement seems false. It does not remove the scoped access control, it only > relaxes it in extensions to types in the same file.
This relaxation makes the resulting scoping decidedly less strong. It is no longer lexical and would require a user to consider all code in the file. This means the strong, compiler-verified guarantee of scoped access that a small number of lines can see a member is eliminated. The whole file must be considered. As others have noted, that defeats the primary purpose of having scoped access control in the first place. > >> The entire reason we're having this discussion is that "fileprivate" is such >> an awkward term for something that's so common in the language. I think the >> main thing we need to fix is the naming of that keyword. > > The name of fileprivate is not reason for this proposal. fileprivate has an > awkward name precisely because it was planned for it to be used less often. > This proposal’s goal is to make private more attractive to fulfil that > original goal. fileprivate’s awkwardness is good, because it attracts > attention to it when it is used. Your previous proposal eliminated this distinction entirely and if I understand correctly you still believe that is the best solution. With that in mind, do you really consider it important to call special attention to same-file, cross-type members? If we’re going to have a distinction in the language, do you really consider this a more important and useful distinction than the distinction supporting the use cases for scoped access? If the answer to either of those questions is no I find it hard to understand how this issue is not simply about having the ability to say `private` most of the time (which is a naming issue not a semantics issue). > >> I continue to believe that the best solution is to revert "private" to mean >> file scope as in Swift 2, and introduce a new "scoped" keyword for those >> developers who are specifically desiring the scoped functionality. This was >> rejected during the discussion because the migration would be too >> disruptive, but it is only disruptive if the migrator rewrites >> "private"->"scoped". I assert that most developers would not *want* that >> migration to happen; most developers use "private" because they want the >> default less-than-internal access control. The few developers who are using >> specifically scoped control can modify their code manually. Under this >> model, scoped access control is still available for those who need it, and >> most users can once again use "private" in cases where it is the natural >> default. >> >> This proposal proposes that "fileprivate" would become a marker to call out >> cases where exceptional across-type access is happening. In practice, I >> don't believe that will happen, simply because there are many existing cases >> of "fileprivate" out there, and this proposal does not suggest migrating >> them. >> >> I also disagree that it's useful to call out "fileprivate" as an exceptional >> case. It's slightly useful, I'll acknowledge, but it would be *more* useful >> to call out the exceptional cases where scope-only control is being used. >> >> So I disagree with the proposal. But I give it only -0.5 because even with >> all of that, this is a better definition for "private" than the current one. >> >> -BJ >> >> On Apr 3, 2017, at 12:34 PM, Douglas Gregor via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> Hello Swift Community, >>> >>> In rejecting SE-0159 >>> <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md>, >>> the core team described a potential direction we would like to investigate >>> for “private” access control that admits a limited form of type-based >>> access control within files. The core team is seeking some discussion here >>> and a motivated volunteer to put together a proposal along these lines for >>> review in the Swift 4 time-frame (i.e., very soon). To be clear, the core >>> team it’s sure this is the right direction to go… but it appears promising >>> and we would *love* to be able to settle the access-control issue. >>> >>> The design, specifically, is that a “private” member declared within a type >>> “X” or an extension thereof would be accessible from: >>> >>> * An extension of “X” in the same file >>> * The definition of “X”, if it occurs in the same file >>> * A nested type (or extension thereof) of one of the above that occurs >>> in the same file >>> >>> This design has a number of apparent benefits: >>> + “private” becomes the right default for “less than whole module” >>> visibility, and aligns well with Swift coding style that divides a type’s >>> definition into a number of extensions. >>> + “fileprivate” remains for existing use cases, but now it’s use it >>> more rare, which has several advantages: >>> + It fits well with the "progressive disclosure” philosophy >>> behind Swift: you can use public/internal/private for a while before >>> encountering and having to learn about “fileprivate” (note: we thought >>> this was going to be true of SE-0025 >>> <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>, >>> but we were clearly wrong) >>> + When “fileprivate” occurs, it means there’s some interesting >>> coupling between different types in the same file. That makes fileprivate a >>> useful alert to the reader rather than, potentially, something that we >>> routinely use and overlook so that we can separate implementations into >>> extensions. >>> + “private” is more closely aligned with other programming languages >>> that use type-based access control, which can help programmers just coming >>> to Swift. When they reach for “private”, they’re likely to get something >>> similar to what they expect—with a little Swift twist due to Swift’s heavy >>> use of extensions. >>> + Loosening the access restrictions on “private” is unlikely to break >>> existing code. >>> >>> There are likely some drawbacks: >>> - Developers using patterns that depend on the existing >>> lexically-scoped access control of “private” may find this new >>> interpretation of “private” to be insufficiently strict >>> - Swift’s access control would go from “entirely lexical” to “partly >>> lexical and partly type-based”, which can be viewed as being more >>> complicated >>> >>> Thoughts? Volunteer? >>> >>> - Doug >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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
