+1 Sent from my iPhone
> On 3 Apr 2017, at 22:21, David Hart via swift-evolution > <[email protected]> wrote: > > >>> 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]> wrote: >>>> >>>> >>>>> On 3 Apr 2017, at 22:54, Douglas Gregor via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>>> On Apr 3, 2017, at 1:13 PM, Matthew Johnson <[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution >>>>>> <[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]> wrote: >>>>>>> >>>>>>> Hello Swift Community, >>>>>>> >>>>>>> In rejecting SE-0159, 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, 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] >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
