<div dir="ltr">this is more in line with other naming conventions, but the names in the updated proposal seem to match the closest to everything else in Swift. I waited for about a week to get everyone's opinion, but I think that we are past the name discussions at this point.<div><br><div class="gmail_quote"><div dir="ltr">On Sun, Mar 27, 2016 at 11:50 PM Matthew Judge 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"><br>
<br>
> On Mar 24, 2016, at 01:13, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> <responding to several posts in this thread at once><br>
><br>
>> On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>> Per Doug’s email, the core team agrees we should make a change here, but would like some bikeshedding to happen on the replacement name for private.<br>
><br>
> What we do with private setters is orthogonal from this proposal, so I’m going to ignore it in this thread. After SE-0025 is resolved, it would be great to have another thread/proposal that discusses reskinning private(set) - presumably as just a modifier on the setter.<br>
><br>
> Similarly, this proposal has nothing to do with “protected” or any other type based access control, so I don’t delve into that at all either.<br>
><br>
> I’ve seen several proposals that seem promising:<br>
><br>
>> On Mar 14, 2016, at 5:49 PM, James Berry <<a href="mailto:jberry@rogueorbit.com" target="_blank">jberry@rogueorbit.com</a>> wrote:<br>
>> I like fileprivate, if that’s the only change. On the other hand, if we want to consider a broader change, what about:<br>
>><br>
>> private symbol visible within the current declaration (class, extension, etc).<br>
>> private(module) symbol visible within the current module.<br>
>> private(file) symbol visible within the current file.<br>
><br>
> I love how this establishes a family with different levels of access control, and unites them under the idea of "levels of being private”. I also like how people would commonly only ever write public and private (because “private(module)” is the default, and "private(file)" is obscure). However, parenthesized modifiers that take a keyword (as opposed to an identifier) are a bit weird and awkward, so it would be nice to avoid them if possible.<br>
<br>
If we borrow the "drop in" from below of private(foo.bar.baz), then maybe:<br>
<br>
private(#module) // expands to current module<br>
private(#file) // expands to current file<br>
<br>
This is slightly more awkward/one character longer, but now it's an identifier in parentheses (or something that expands to an identifier).<br>
<br>
I'm not sure I like this in practice unless it is fairly rare to actually have to type. If "private" at the top level of a file meant fileprivate (as I suggested in my other reply a few minutes ago) that would significantly reduce the need to type something other than just private.<br>
<br>
><br>
>> On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>> public<br>
>> private-module<br>
>> private-file<br>
>> private<br>
><br>
> This follows the same sort of structure as James’ proposal, without the parens. It has the same advantages, but trades them with hyphenated decl modifiers. We don’t do that, but it is a good direction.<br>
><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>
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></div></div>