On 05.04.2017 7:02, Chris Lattner via swift-evolution wrote:
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
Another way to explain this is as a relaxation of the Swift 3 access
control, to would allow private members in a type to also be accessible in
extensions to that type, so long as they are in the same file.
While I typically try to avoid chiming in on early discussions like this, I
pretty strongly believe that this is a good solution for the reasons you
mention:
- fileprivate should really become much more rare, which makes it more
meaningful and significant where it occurs. This was the original idea and
intent behind SE-0025.
- Similarly, this simplifies access control for most people. Most people
will now only care about private/internal/public. fileprivate will become
an expert feature used in specific cases to solve a specific class of
problems. Progressive disclosure of complexity is important.
- This design is true to the existing design of Swift: we want to
encourage the implementation of types to be freely broken into extensions.
This alignment with extension oriented programming was the one important
virtue of the Swift 1/2 access control design that Swift 3 lost.
From a pragmatic perspective, I feel like this is a great solution that
really does solve the problems we have with current access control, all
without breaking source compatibility. This is also a major progression
from where we are, and doesn’t appear to cut off any future directions
(e.g. submodules) since those are cross-file concepts that live between
internal/public or between fileprivate/internal.
If we have Swift2's 'private' (instead of fileprivate) and 'scoped'(instead
of current 'private'), then such 'private' can naturally mean "private to
submodule" *especially* if file will be treated as un-named submodule.
What we'll have with 'fileprivate' to have a submodule-wide access? New
keyword 'submoduleprivate' ? Will extend meaning of proposed 'private' ?
Rename 'fileprivate' to something else?
Just wonder if this direction was really discussed and core team has some
thoughts about this.
Just MHO, but I think that the rhetorical attempts to paint this as being
similar to “protected” are unsound.
-Chris
_______________________________________________
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
