<div dir="ltr">no, I still want extensions to be able to hide their implementation details from anything else (including other extensions of the same type or the "root" class definition). And I also want to be able to hide stuff in the root class definition from extensions of the same type. I just don't want an ability to inject new class in a scope to get access to its implementation details.<div><br></div><div>That said, I will not include it in the updated proposal (i'll only update the names) and will start a new thread after SE-0025. Also, I think that it's an edge case, and it could be argued either way.<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 24, 2016 at 11:47 AM Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Mar 24, 2016, at 10:40 AM, Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div>This is why I'd like private to mean exactly that (no nested class should get access). Then the meaning is clear: it's as private as it can be :-)</div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>In that case, you want a type-based access control mechanism, not a scope-based access control mechanism. Your proposal that was provisionally accepted is for a scope-based mechanism. </div><div><br></div><div>Chris’s request for bikeshedding on names did not include a request to bikeshed on semantics. Any discussion about type-based access control should happen in a different thread IMO.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><br>Private and public have well defined meaning. We <br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 24, 2016 at 11:33 AM Ross O'Brien via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">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>
_______________________________________________<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" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div></div></blockquote></div></div></div>