[swift-evolution] [Draft] Fix Private Access Levels

Tony Allevato tony.allevato at gmail.com
Mon Mar 6 23:18:01 CST 2017

On Mon, Mar 6, 2017 at 1:27 PM Nevin Brackett-Rozinsky via swift-evolution <
swift-evolution at swift.org> wrote:

> I support this proposal to restore the file-based meaning of “private”.

This is where I fall on this matter as well.

I've leaned back from all the visibility/submodule discussions because I
haven't had the time to read them in-depth enough to give what I thought
was a fair assessment, but from brief scans of many of them, I find them to
add far too much complexity to the language for little *real* gain.

The most important visibility boundary is outside-module (public) vs.
inside-module (internal); one could argue (as I believe Slava did in
another thread) that everything else is frivolous. I tend to agree with
that, but I would still make special allowances for "private" (in its
original form, meaning file-private) because I've personally found it
valuable in code generation scenarios. Specifically, since Swift modules
are determined by build configurations, we don't have control over which
module our code gets generated into. This means that internal isn't
sufficient—we still want to hide certain parts of that generated code from
other consumers of that code within the same module, and file-private
achieves that perfectly. If someone attempted to circumvent those
protections by adding code to the generated file, it would just get
clobbered the next time the generator runs.

Outside of that, I don't think it's that productive to encourage developers
to finely tune visibility dials that really only serve to protect them from
themselves or teammates.

> Personally, I do not think we need any more fine-grained access level than
> this, so I lean toward solution 1 (remove the scoped access level).
> However, I would also be okay with solution 2 (rename the scoped access
> level to scoped) if other people have a strong need for it.
> Nevin
> _______________________________________________
> 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/20170307/96c12128/attachment.html>

More information about the swift-evolution mailing list