[swift-evolution] Type-based ‘private’ access within a file

[Goffredo Marocchi]

Sent from my iPhone

> On 4 Apr 2017, at 01:01, David Waite via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Soft -1 for four reasons:
> 
> 1. I would expect private to be used to hide implementation details and type invariants from all code, to encapsulate and protect the unsafe bits. Think the possibility to put the instance into an illegal state, or to modify its state outside of its defined threading model. Why would an extension be trusted to do this? This smacks of a ‘protected’ mode for extensions.

Not everybody would hate that ;), but seriously it seemed a strong request in all our discussions about this and it comes at a very small cost.

> 
> 2. This makes the model more confusing, and increases overlap with file private. It seems this is here just to appease the people who think “fileprivate” is an ugly wart, while not having time to formulate a strategy to eliminate file private. The real issue is that there isn’t a level between fileprivate and internal.
> 
> 3. This seems to make the issue of large files even worse, by encouraging the use of ‘private’ as a way of exposing an extension-specific API of a type that is only accessible by putting extensions in the same file
> 
> 4. From discussions on migration, I believe we can leave the option open of widening private later as part of a tasked redesign of access control after Swift 4.0. I’d prefer to not widen private before we have evaluated access control as a whole, as I believe private as it is today is the lowest, most restrictive-but-usable level of access control.

I am not sure this kind of change will easily happen for Swift 5, I say let's not waste this chance.

> 
> -DW
> 
>> On Apr 3, 2017, at 12:34 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170404/d788f7df/attachment.html>