> On Apr 3, 2017, at 5:32 PM, Daniel Duan <[email protected]> wrote: >> On Apr 3, 2017, at 2:22 PM, John McCall via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> On Apr 3, 2017, at 5:21 PM, David Hart <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>>> On 3 Apr 2017, at 23:19, John McCall <[email protected] >>>> <mailto:[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 :) >> >> I agree. This is why we asked swift-evolution to consider this last tweak: >> it is realistically the last opportunity to do it. > > Questions: > > 1. does this mean no changes like this will happen to Swift 5?
I think it is likely that we will not accept any proposals that change the basic rules of existing language features, no, unless it's a very serious problem or a very minor change. > 2. can core team provide any discussions/thoughts that they had about > submodules, for a “future consideration” section in this proposal? We have not had any serious conversations about submodules. John. > >> 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 >>>>>>>>> <[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] <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
