> On 3 Apr 2017, at 23:19, John McCall <[email protected]> wrote: > > >> On Apr 3, 2017, at 5:11 PM, David Hart via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> On 3 Apr 2017, at 22:54, Douglas Gregor via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>>> On Apr 3, 2017, at 1:13 PM, Matthew Johnson <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>>> >>>>> On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> I’m concerned that we will have access control changes in a future >>>>> version yet again, when light-weight modules, or other type of enforced >>>>> namespace is introduced. Does the core team have any foresight on how >>>>> this change would interact with such things? I had the same concern for >>>>> SE-0159 as well. >>>>> >>>>> There’s a implicit drawback to all access control changes that >>>>> migrator/fix-its cannot fix: we organize our code with tools in the >>>>> language. Some colleague of mine had came up with schemes that combines >>>>> file scope and Swift 3 `private` to hide details among separate protocol >>>>> extensions, for example. Code ends up in certain places for a reason and >>>>> updating access control invalidate those reasons. >>>>> >>>>> I hesitate to support any changes until we have some ideas for what >>>>> “ultimate glory” looks like. >>>> >>>> +1. >>>> >>>> If we must make a change in Swift 4, the only change I can support for >>>> Swift 4 is renaming the existing access levels. >>> >>> We don’t have to make a change in Swift 4. If there’s a change that can >>> resolve this issue, great… >> >> I still think this is a worthwhile goals. >> >>>> That would cause some churn but can be automated and has no semantic >>>> impact. I feel strongly that the semantics of access control should >>>> remain the same until submodules and access control can be considered >>>> together as part of the theme of a larger Swift release. I believe the >>>> churn caused by continuing to poke at the semantics of access control >>>> without addressing the broader issues would be a mistake that would cause >>>> further frustration in the community. >>> >>> … but if not, then let’s shelve access control changes until some time when >>> we can considered it holistically with something like submodules, as you >>> note above. >> >> Won’t making big modifications later be even more problematic than now, in >> the name of source stability? > > Yes. Big changes along these lines will not be considered later. At best, > it would be possible to "re-cast" existing behaviors in light of new features > — that is, significantly changing *how we talk about those behaviors*, and > changing how we understand them in the broader language, but not actually > changing the behaviors themselves.
That’s why I don’t buy the “lets postpone this discussion to a future submodule design” argument. Let’s get this in a reasonable state now :) > John. > > >> >>>> As others have already pointed out, code has been developed and organized >>>> with the new scoped access model in mind. I think the frustration over a >>>> semantically neutral, fully automated migration to new names would be >>>> pretty minimal >>> >>> The core team felt strongly that we couldn’t change these keywords. Source >>> stability is important to Swift 4, and “don’t break source compatibility so >>> much” is one of the top requests we hear from Swift developers, much more >>> so than requests for specific new language features. >>> >>>> and certainly much less than the frustration over the suggested semantic >>>> change. >>> >>> This isn’t clear to me. There could certainly be frustration over the >>> suggested semantic change, for a number of reasons: >>> >>> * It’s not as “tight” a meaning of private as the current scope-based >>> private. >>> * It means we have a hybrid type-based/scope-based model. >>> * It’s the third meaning of ‘private’ in three years. >>> >>> However, it is unlikely to break code (one would need to construct an >>> ambiguity between two private declarations in different extensions of the >>> same type in the same file), and causes zero code churn, because it’s >>> widening the meaning of “private”, not changing it. >>> >>> - Doug >>> >>>> >>>>> >>>>>> On Apr 3, 2017, at 11:34 AM, 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 >>>>> <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] <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
