<div dir="ltr">This would address my concerns.<div><br></div><div>rob</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 24, 2017 at 10:27 AM, Ross O'Brien 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"><div dir="ltr">We should be clear about this, because it seems to me that this is the source of the 'cognitive load' problem:<div><br></div><div>Following Alternative 3,</div><div>private properties in scopes, would become "scoped".</div><div>fileprivate properties in or out of scopes would become "private".</div><div>private types, such as protocols, classes, etc., would *stay* "private". The keyword would consistently mean private to the file, instead of changing its meaning at different scopes.</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 24, 2017 at 1:49 PM, Ricardo Parada 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">After reading the discussions it seems to me that renaming private -> scoped and fileprivate -> private might keep both sides happy.<br>
<div class="m_6362685011163851602HOEnZb"><div class="m_6362685011163851602h5"><br>
<br>
<br>
> On Mar 24, 2017, at 9:06 AM, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> On <a href="tel:24.03.2017%2011" value="+12403201711" target="_blank">24.03.2017 11</a>:47, Jonathan Hull via swift-evolution wrote:<br>
>> Nevin had a fantastic proposal for submodules which changed private to mean<br>
>> “private to the submodule”, where each file was implicitly a submodule<br>
>> unless you declared otherwise. Simple and elegant.<br>
><br>
> Currently I don't see how submodules can eliminate the needs of 'scoped'(current 'private') access level. Even in submodule (even if submodule will be a "namespace" line feature like "submodule Name{..}" and we can have number of such declarations in the same file) - 'scoped' access is valuable even for single type declaration. Probably I don't understand something.<br>
><br>
> But as for fileprivate - it is really logically to have it named 'private' and it can naturally be used in submodules as "private to submodule" just like "private to file" currently.<br>
><br>
> So I do think the right move currently is to rename fileprivate->private, private->scoped and then, when(if!) we have submodules - we can change something.<br>
> Rename will remove the huge confusion users(especially novice) have with 'fileprivate' vs 'private'; experience shows that *actually* programmers use 'fileprivate' a lot and this is some kind of Swift/iOs programming style, and fileprivate is awkward keyword, and many(all? ;-) just want 'private' means "in this file".<br>
> Also novice programmer can know just about 'public', 'internal' and 'private' - these three logically united access modifiers,all are file-scoped, but more experienced programmer has no problems teach what 'scoped' means and why one want to use it.<br>
><br>
>><br>
>><br>
>>> On Mar 23, 2017, at 6:27 PM, Drew Crawford via swift-evolution<br>
>>> <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Sent from my iPhone<br>
>>> On Mar 23, 2017, at 6:41 PM, David Hart <<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a><br>
>>> <mailto:<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>>> wrote:<br>
>>><br>
>>>> I have difficulties imagining a submodule proposal that could allow us<br>
>>>> to eliminate fileprivate. Care to give an example?<br>
>>><br>
>>> The obvious example would be Rust. Rust has exactly two visibilities,<br>
>>> and merely one keyword. By default, members are "private" which is<br>
>>> visible inside the module (so, like Swift's internal). The "public"<br>
>>> keyword is similar to Swift.<br>
>>><br>
>>> The reason this works is that unlike in Swift where a module is something<br>
>>> like a library or framework (Rust calls those "crates"), in Rust modules<br>
>>> in are (explicitly) lexically scoped; a "mod myscope {}" module can be<br>
>>> created for the portion of the file for which the member should be<br>
>>> visible and it won't be visible outside that scope. Likewise,<br>
>>> "fileprivate" can be achieved by enclosing the file in a "mod MyFile {}".<br>
>>> And like all lexical scopes, they can be recursively nested to arbitrary<br>
>>> depth to achieve any number of visibility behaviors (e.g., declare a<br>
>>> module for the first half of two files) that would require complex new<br>
>>> keywords to achieve in Swift. Finally there are some shortcut features<br>
>>> like the ability to infer a module structure from the file system.<br>
>>><br>
>>><br>
>>><br>
>>> In Swift, modules are presently tied to libraries/frameworks in a 1:1<br>
>>> way. Because of this we lack the flexibility of recursively nestable<br>
>>> modules of other languages and this is the underlying problem that<br>
>>> motivates both scoped/private and fileprivate. If we fixed that, we<br>
>>> would actually not need either keyword.<br>
>>><br>
>>> <a href="http://rustbyexample.com/mod/visibility.html" rel="noreferrer" target="_blank">http://rustbyexample.com/mod/v<wbr>isibility.html</a><br>
>>> <a href="https://doc.rust-lang.org/book/crates-and-modules.html" rel="noreferrer" target="_blank">https://doc.rust-lang.org/book<wbr>/crates-and-modules.html</a><br>
>>> ______________________________<wbr>_________________<br>
>>> swift-evolution mailing list<br>
>>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>><br>
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<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/mailma<wbr>n/listinfo/swift-evolution</a><br>
>><br>
> ______________________________<wbr>_________________<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/mailma<wbr>n/listinfo/swift-evolution</a><br>
______________________________<wbr>_________________<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/mailma<wbr>n/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div><span style="font-family:arial,helvetica,sans-serif;font-size:20px"><span style="color:rgb(64,64,65)"><strong><span style="font-size:14px">Robert </span></strong></span><span style="font-size:14px"><span style="color:rgb(64,64,65)"><strong>Hedin </strong></span><span style="color:rgb(105,105,105)"><span style="font-size:16px">|</span></span></span></span><span style="font-family:arial,helvetica,sans-serif;font-size:14px"><span style="color:rgb(64,64,65);margin-left:5px">Dir Software Engineering</span></span></div><span style="font-family:arial,helvetica,sans-serif"><div style="color:rgb(64,64,65);font-weight:bold;font-size:14px"><span style="color:rgb(105,105,105);font-weight:normal;font-size:12px"><strong>w:</strong> 770-226-2650</span><span style="color:rgb(105,105,105);font-weight:normal;font-size:12px"> <strong>e:</strong> <a href="mailto:robert.hedin@weather.com" target="_blank">robert.hedin@weather.com</a></span></div></span><div><div> <a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"></a><a href="http://weather.com/apps" target="_blank"><a href="http://weather.com/apps" target="_blank"><img alt="" src="http://www.theweathercompany.com/sites/default/files/twco_emailsig_225x92_buffered_final.png" style="height:92px;width:225px"></a></a><br>
</div></div></div>
</div>