<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 14, 2016, at 8:36 PM, Patrick Pijnappel 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="">Another +1 for James' idea to use private(module), private(file), private:<br class=""><div class="">- It avoids ambiguity whether internal/private/local is more restrictive and replaces it with a single axis, public vs. private.<br class=""></div><div class="">- The two longer terms, private(module) and private(file), are the least used ones.</div><div class="">- As mentioned by Joe, it admits clean extension to groupings between file and modules in the future (e.g. submodules).</div><div class=""><br class=""></div><div class="">The only question is (as Sean mentioned) how this combines with the syntax for setter access level, e.g. the current private(set). Options:</div><div class="">- Unnamed 2nd argument, giving private(file), private(file, set), private(set).</div></div></div></blockquote><div><br class=""></div><div>We could conceivably reskin private(set) too. A lot of people complain it's "weird" as-is, for better or worse.</div><div><br class=""></div><div>-Joe</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">- Named 2nd argument, giving e.g. private(file), private(file, accessor: set), private(accessor: set). Less ambiguity but longer.</div><div class="">- Not using multiple arguments, but that'd probably break consistency with the other unification efforts going on to make everything look like function calls.</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Mar 15, 2016 at 1:42 PM, Sean Heber 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">Although really, why not just use “file” instead of “internal” since it won’t burn any keywords or cause any other conflicts as far as I know.<br class="">
<br class="">
l8r<br class="">
Sean<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
<br class="">
> On Mar 14, 2016, at 9:38 PM, Sean Heber <<a href="mailto:sean@fifthace.com" class="">sean@fifthace.com</a>> wrote:<br class="">
><br class="">
> I, too, prefer it to be more like this:<br class="">
><br class="">
> public // unchanged<br class="">
> module // currently internal<br class="">
> internal // currently private<br class="">
> private // new hotness<br class="">
><br class="">
> l8r<br class="">
> Sean<br class="">
><br class="">
><br class="">
>> On Mar 14, 2016, at 7:50 PM, Jo Albright via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
>><br class="">
>> +1<br class="">
>><br class="">
>> I like this a lot. Name ideas : enclosed, filelocal, fileonly, filelock, fileaccess, fileprivate, insidefile, inner. I also like Erica’s filebound & file fixed.<br class="">
>><br class="">
>> By Erica’s suggestion about switching…<br class="">
>><br class="">
>> - public<br class="">
>> - modular, modulelock, packaged (module only)<br class="">
>> - internal (file only)<br class="">
>> - private<br class="">
>><br class="">
>> Designer . Developer . Nerd<br class="">
>> Jo Albright<br class="">
>><br class="">
>><br class="">
>>> On Mar 14, 2016, at 8:18 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
>>><br class="">
>>> 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 class="">
>>><br class="">
>>> To summarize the place we’d like to end up:<br class="">
>>><br class="">
>>> - “public” -> symbol visible outside the current module.<br class="">
>>> - “internal” -> symbol visible within the current module.<br class="">
>>> - unknown -> symbol visible within the current file.<br class="">
>>> - “private” -> symbol visible within the current declaration (class, extension, etc).<br class="">
>>><br class="">
>>> The rationale here is that this aligns Swift with common art seen in other languages, and that many people using private today don’t *want* visibility out of their current declaration. It also encourages “extension oriented programming”, at least it will when some of the other restrictions on extensions are lifted. We discussed dropping the third one entirely, but think it *is* a useful and important level of access control, and when/if we ever get the ability to write unit tests inside of the file that defines the functionality, they will be a nicer solution to @testable.<br class="">
>>><br class="">
>>> The thing we need to know is what the spelling should be for the third one. Off hand, perhaps:<br class="">
>>><br class="">
>>> fileprivate<br class="">
>>> private(file)<br class="">
>>> internal(file)<br class="">
>>> fileaccessible<br class="">
>>> etc<br class="">
>>><br class="">
>>> Some other thoughts on the choice:<br class="">
>>> - this will be a declaration modifier, so it will not “burn” a keyword.<br class="">
>>> - if will be a uniquely Swift thing, so there is virtue in it being a googlable keyword.<br class="">
>>><br class="">
>>> Thoughts appreciated.<br class="">
>>><br class="">
>>> -Chris<br class="">
>>><br 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/mailman/listinfo/swift-evolution</a><br class="">
>><br 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/mailman/listinfo/swift-evolution</a><br class="">
><br class="">
<br 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/mailman/listinfo/swift-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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>