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
<[email protected] <mailto:[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. 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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected] <mailto:[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
