<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Mar 6, 2017 at 1:27 PM Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_extra gmail_msg">I support this proposal to restore the file-based meaning of “private”.</div></div></div></blockquote><div><br></div><div>This is where I fall on this matter as well.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"></div><div class="gmail_extra gmail_msg">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.<br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"></div><div class="gmail_extra gmail_msg">Nevin</div></div></div>
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div>