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

[Xiaodi Wu]

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/43d4d42d/attachment.html>