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

[David Hart]

> On 5 Apr 2017, at 13:51, Shawn Erickson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Wed, Apr 5, 2017 at 4:31 AM Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
>> 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
>> > <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
>> >
>> > 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.
> 
> Now that is a change I would 100% support when factoring in sub modules. I would support that even before submodules come around but would prefer it to wait for submodules.

But the core team said there will not come back on their decision. We should discuss what can be done instead, not repeat the same arguments and opinions which bring us nowhere.

> -Shawn
> _______________________________________________
> 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/20170405/e0ab2f96/attachment.html>