> On 6 Apr 2017, at 03:34, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > >> On Apr 5, 2017, at 7:11 PM, Colin Barrett via swift-evolution >> <[email protected]> wrote: >> >> I'm broadly in favor of this. >> >>> On Mon, Apr 3, 2017 at 2:35 PM 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 >> >> I think it might not as complicated as it may first appear. I haven't fully >> convinced myself of this, but I believe that it would be lexically scoped >> modulo inlining extensions. >> >> To put it somewhat more formally (and awkwardly), if one imagines a textual >> transformation which blindly inlines any extension in a single file into >> their type definitions (should those definitions occur within that file) >> then accessing a "private" member in the original file would compile if and >> only if the access would be lexically scoped if the above postulated >> transformation were to be applied to it. >> >> This is a pleasing property (to me anyway) as it means that it is unlikely >> (impossible?) for moving code from one extension (or definition) to another >> to cause a compilation failure. >> >> Take this with a grain of salt of course, as there's probably an edge case >> I'm not thinking of :P (This is why we write proofs!) > > This is a very interesting perspective Colin. This idea seems to align well > with the intent for extensions that Chris stated earlier. This way of > thinking about it does make the proposal much cleaner conceptually. If we’re > going to adopt this perspective I think we should go all the way - same file > extensions really should be inline semantically. This means same file > extensions would also have the ability to include stored properties which is > something many people have asked for. > > I wonder how David and the core team would feel about modifying the proposal > to adopt this “inline same file extensions" perspective.
I like the idea 😊 I have small reserves as to the confusion it could cause new users to understand the semantic differences between the two "kind" of extensions (same file and seperate file) > IMO this motivates the proposal better by acknowledging that most developers > in the community use same file extensions for purely organization purposes. > The implicit desire is that they be transparent boundaries that carry no > semantic weight at all. I think a proposal with this kind of motivation is > more likely to be well received by the broader community than a change that > is only focused on access control in a very specific context. Instead of > “why do they keep changing access control” the response might be “yay, > extensions finally work the way I always wanted them to”. > > Cheers, > Matthew > >> >> Cheers, >> -Colin >> >>> 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
