[swift-evolution] Swift evolution proposal: introduce typeprivate access control level
Jonathan Hull
jhull at gbis.com
Fri Dec 2 16:30:24 CST 2016
> 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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161202/87e295d8/attachment.html>
More information about the swift-evolution
mailing list