[swift-evolution] Type-based ‘private’ access within a file
svabox at gmail.com
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.
> 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
> 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
>>> 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
>>> + “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
>>> Thoughts? Volunteer?
>>> - Doug
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution