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

Mon Apr 3 16:54:29 CDT 2017

On 03.04.2017 23:13, Matthew Johnson via swift-evolution wrote:
>
>> On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution
>> <swift-evolution at swift.org <mailto:swift-evolution at 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.  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.
>
> 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 and certainly much less than the frustration over the
> suggested semantic change.
>
> Renaming would restore the original intent of SE-0025 which was to leave
> private alone and introduce a new name for scoped access.  One of the big
> reasons that approach was rejected is that we did not have consensus on
> what to call it.  Now that we seem to have reached consensus about what the
> name should be if it is changed it is reasonable to correct the mistake
> that was made in Swift 3.
>
> Finally, I am not at all convinced that type-based private is the right
> semantics.  I think the strictly hierarchical foundation of the existing
> access levels is a much stronger design.  The suggested proposal for a
> same-file type-based approach has already resulted in requests for
> expanding that model to the whole module.  Types and scopes are orthogonal
> dimensions.  If we want to consider a hybrid model for access control I
> think it is best not to rush.  We should take our time and consider it
> properly in the future.
>

Fully support Matthew's opinion.

Moreover, I think that we need *additional* access level(to current 
'private'), which will mean 'can be accessed from extensions and subtypes 
in the same *module*' to be able to split type's conformances to number of 
files and don't make implementation details accessible&visible for whole 
module. (there was 'extensible' modifier discussed previously).

Current 'private' has its value to limit access to definition scope, the 
most restrictive level. And we need a pair for it - that will extend the 
allowed scope to "extensions and subtypes".

So, IMO, in this case we have clear model: public/internal/private as 
file-based "basic" access levels, and scoped/extensible as scope based 
"advanced" access levels. One teaches basic access levels and can use them, 
and then can read about "advanced" access levels.

>>
>>> On Apr 3, 2017, at 11:34 AM, Douglas Gregor via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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
>