This is very disappointing. We can’t realistically get access controls correct until we have a story around submodules, etc. Those things are out of scope for Swift 4, and we can’t change access controls after Swift 4. Catch-22.
We should hold off on doing anything now, and redesign holistically when we do the rest. -1. This just adds tires to the tire fire. I feel like it only adds to the confusion between private and fileprivate by making them less distinct from one another. If we have to make a change now (because we won’t be able to later… which I would strongly ask you to reconsider), then I would go with the renaming proposal. It is not at all ideal, but it would at least make things a little better long-term if we are to be stuck with the design. I regret pretty much all of the proposals in Swift 3 which were accepted based on “We have to do this now. or else…” Pretty much universally, it would have been better to wait. > On Apr 3, 2017, at 2:22 PM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Apr 3, 2017, at 5:21 PM, David Hart <da...@hartbit.com >> <mailto:da...@hartbit.com>> wrote: >> >> >>> On 3 Apr 2017, at 23:19, John McCall <rjmcc...@apple.com >>> <mailto:rjmcc...@apple.com>> wrote: >>> >>> >>>> On Apr 3, 2017, at 5:11 PM, David Hart via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>>> >>>>> On 3 Apr 2017, at 22:54, Douglas Gregor via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> >>>>>> On Apr 3, 2017, at 1:13 PM, Matthew Johnson <matt...@anandabits.com >>>>>> <mailto:matt...@anandabits.com>> wrote: >>>>>> >>>>>>> >>>>>>> On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution >>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 :) > > I agree. This is why we asked swift-evolution to consider this last tweak: > it is realistically the last opportunity to do it. > > John. > >> >>> 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 >>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >>>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
