<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The primary point of access modifiers is communication, with the secondary point of something like ‘internal’ or ‘final’ to be compiler optimization. Other languages do just fine with just having naming conventions for implementation details, rather than having the compiler enforce that behavior (or even, start having the language itself enforce the naming conventions)</div><div class=""><br class=""></div><div class="">Our justification of access modifiers should be based around communication and compiler optimization, and not completeness against possible options or against features in other languages.</div><div class=""><br class=""></div><div class="">So private and fileprivate serve to communicate that something is an implementation detail of a type, and that manipulation without understanding the type could lead to you (for example) invalidating the type invariants. This IMHO is a useful enough concept to warrant a keyword to communicate.</div><div class=""><br class=""></div><div class="">However, my opinion is that it absolutely *doesn’t* warrant two keywords, and “private” is the less useful of the two due to it blocking extensions.</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 16, 2017, at 3:34 PM, Slava Pestov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat because this might be controversial here.<div class=""><br class=""></div><div class="">I think both ‘private’ and ‘fileprivate’ are unnecessary complications that only serve to clutter the language.</div><div class=""><br class=""></div><div class="">It would make a lot more sense to just have internal and public only. No private, no fileprivate, no lineprivate, no protected. It’s all silly.</div><div class=""><br class=""></div><div class="">Slava</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 15, 2017, at 7:40 AM, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><span style="font-size:12.800000190734863px" class="">"Either keep it or drop it, but don't keep fiddling with it."</span> sums up my position well.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Feb 15, 2017 at 7:00 AM, Brent Royal-Gordon via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> Keeping with the spirit of Swift and staying consistent with its design, I see two plausible meanings for private:<br class="">
><br class="">
> Private could mean either:<br class="">
> 1) private to the file (Swift 2 semantics)<br class="">
> 2) accessible only to the current type/scope and to extensions to that type that are in the current file.<br class="">
><br class="">
> I don’t think we’ve ever evaluated and debated approach #2 systematically.<br class="">
<br class="">
</span>For what it's worth:<br class="">
<br class="">
I was opposed to SE-0025, but since I lost, I have tried to use `private` wherever it made sense, rather than fighting with the language.<br class="">
<br class="">
Sometimes, the change of keyword makes no difference. Other times, it's a hassle, because I have to switch between `private` and `fileprivate` as I redesign things, with little perceived benefit. I'd say the split between these is about 50/50.<br class="">
<br class="">
On a few occasions, I *have* genuinely appreciated the SE-0025 version of `private`. These involved cases where I wanted to ensure that instance variables were only manipulated in certain ways, using interfaces I had specifically designed to handle them correctly. For instance, I might have two parallel arrays, and I wanted to make sure that I only added or removed elements from both arrays at once. I could do this with `fileprivate` by splitting the type into two files, but it was more convenient to do it in one.<br class="">
<br class="">
In these cases, switching to #2 would *completely* defeat the purpose of using `private`, because the extensions would be able to directly manipulate the private instance variables. I would no longer gain any benefit at all from `private`. All of my uses would either fall into "makes no difference" or "it's a hassle".<br class="">
<br class="">
I do not support the idea of changing `private` to mean #2. Doing so would eliminate the few decent use cases I've found for `private`. Either keep it or drop it, but don't keep fiddling with it.<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
--<br class="">
Brent Royal-Gordon<br class="">
Architechies<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>