> On Apr 3, 2017, at 9:16 PM, Jonathan Hull <jh...@gbis.com> wrote: > > 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.
I'm not sure what sort of holistic redesign you're imagining. John. > -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 <mailto: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 <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
