<div style="white-space:pre-wrap">Perhaps internal is valuable here then?<br>Maybe: public, moduleinternal, fileinternal, private.<br>Or just: public, internal, fileinternal, private.<br>Or, more radically: public, internal, internal(#file), private.<br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 24, 2016 at 10:32 AM Ross O'Brien 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">I agree that 'private' still feels too subjective on its own. It's intuitively 'not public'; it's not intuitively the access term for 'declaration only'.<div><br></div><div>I'm not opposed to fileprivate and moduleprivate, if we like those terms. I'd just prefer a corresponding scopeprivate or declarationprivate.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 24, 2016 at 3:21 PM, Brandon Knope via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> How about we continue this trend, and follow other existing Swift keywords that merge two lowercase words (associatedtype, typealias, etc), and use:<br>
><br>
> public<br>
> moduleprivate<br>
> fileprivate<br>
> private<br>
><br>
> The advantages, as I see them are:<br>
> 1) We keep public and private meaning the “right” and “obvious” things.<br>
> 2) The declmodifiers “read” correctly.<br>
> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward parenthesized keyword approach.<br>
> 4) The unusual ones would be “googable”.<br>
> 5) Support for named submodules could be “dropped in” by putting the submodule name/path in parens: private(foo.bar.baz) or moduleprivate(foo.bar). Putting an identifier in the parens is much more natural than putting keywords in parens.<br>
><br>
> What do you all think?<br>
><br>
> -Chris<br>
><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</span>I'm not sure my wording will be perfect here, but I will try: I still believe that private is implied in "module" and "file" and the problem is in the name of the plain "private" keyword.<br>
<br>
You may say private is obvious, but when you have moduleprivate and fileprivate, the natural question I ask is "What remaining kind of private is there?" so private's obviousness is muddied for me when next to moduleprivate and fileprivate.<br>
<br>
I will say I would prefer these keywords to the proposed parameter keywords. I just think:<br>
<br>
file -> implies file only<br>
module -> implies module only<br>
<br>
where adding private to them only adds noise (I.e. fileprivate and moduleprivate)<br>
<br>
Brandon<br>
<div><div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>