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

[Jay Abbott]

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/3964114e/attachment.html>