[swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Xiaodi Wu]

For those who are considering this topic, the existing document here is a
good resource:
https://github.com/apple/swift/blob/master/docs/AccessControl.rst
Note that "class-only" and "protected" access levels are specifically
called out as non-goals for Swift, with accompanying justification. Perhaps
those who disagree with the design could catalog warts that would be
addressed with an alternative design?


On Sat, Dec 3, 2016 at 1:46 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> An interesting format. Since it's a list, I'm not sure how to go about
> commenting on the items already there with which I disagree. IMO, the
> format doesn't lend itself to discussion.
>
> For example, _why_ do you want friend classes? By contrast, it's been said
> on this list that not having them is considered a feature, and that friend
> classes are a mistake. Should I just go ahead and write "not having the
> ability to list specific classes and functions that can access a
> property/function" as a bullet point? It seems that's not very productive.
>
>
> On Sat, Dec 3, 2016 at 10:59 AM, Jay Abbott <jay at abbott.me.uk> wrote:
>
>> No idea if this will be useful, or if it will work, but I created a
>> public trello board:
>>
>> https://trello.com/b/fmv4uV3n/swift-access-control
>>
>>    - Pre-populated with a few of the things already mentioned.
>>    - There’s a link on the board to gain edit access.
>>
>> It’s possible this will be an utter disaster, or that nobody will use it
>> at all, so go ahead and add new lists/cards with abandon.
>> ​
>>
>> On Fri, 2 Dec 2016 at 22:38 Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> Well, that's literally what I just mentioned above. I'd be fine with
>>> getting rid of private and fileprivate.
>>> On Fri, Dec 2, 2016 at 16:30 Jonathan Hull <jhull at gbis.com> wrote:
>>>
>>> On Dec 2, 2016, at 2:21 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>> I'm not sure why that last scenario couldn't be accommodated by
>>> submodules. Why wouldn't you put those two specific submodules in the same
>>> parent submodule?
>>>
>>>
>>> Why even have private and fileprivate? Why not just make everything
>>> internal?  Same reason…
>>>
>>>
>>>
>>> On Fri, Dec 2, 2016 at 15:35 Jonathan Hull via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> Assuming that this is true (I tend to agree), why do we need any extra
>>> syntax at all?  Couldn’t we just make everything accessible to extensions?
>>>
>>> Alternatively, if we do want to hide some things from extensions by
>>> default (to prevent accidental use), I had a proposal a while back which
>>> had a very simple way to control what is shared. Basically, you could have
>>> a special import statement which allows you to extend knowledge/access of
>>> the hidden parts to another file (you were also able to limit the range of
>>> this ability if needed).
>>>
>>> Most of the feedback at the time seemed to want submodules instead, but
>>> I still think there will still eventually be a need for something like
>>> this. As others have mentioned, the current system is inflexible
>>> (especially to the common use cases), causing people to keep requesting
>>> additions… and forcing them to give wider access than they want to in the
>>> mean time.  Even if we have sub-modules, someone will want to share with a
>>> specific other sub-module, but not make things public.
>>>
>>>
>>>
>>> On Dec 1, 2016, at 1:31 AM, Tino Heth via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>
>>> It also means that anybody who want to access your private var will just
>>> have to write an extension to expose it.
>>>
>>> imho this is wrong thinking:
>>> Access control is no tool to offer real "protection" — it can't stop
>>> someone who wants to break a system.
>>> Especially in the world of open source, it is merely an advice from the
>>> author not to do certain things.
>>> _______________________________________________
>>> swift-evolution mailing list
>>> 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
>>>
>>> _______________________________________________
>>> 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/20161203/ddd30153/attachment.html>