Or, since many designs for submodules are possible, we can proceed to make the best decision *now* with respect to access levels, confident that there will be a good design for submodules whether or not there exist both scoped and file-based private access. That is to say, any future submodule proposal would be judged on how well it accommodates desired use cases if one type of private is removed, and any future design for submodules would be judged on how well it fits with the current set of access levels without duplicating functionality with a different syntax if both types of private are retained.<br><br>One very important thing about the evolution process (IMO) is that decisions made aren't revisited without compelling changes in circumstances. It is highly unusual that fileprivate vs. private is now going through this process for a _third_ time. I submit that it is untenable that every version of Swift should consider a change to the access modifiers. Given, as some have said above, many different submodule designs are possible whatever the number of access levels, I would expect that we would not revisit this topic again for the foreseeable future, whatever the decision is. That is, the question being asked here is, is it better for Swift to have both fileprivate and private for all time, or one file-scoped private for all time?<br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 23, 2017 at 21:48 Charles Srstka 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 style="word-wrap:break-word" class="gmail_msg"><blockquote type="cite" class="gmail_msg">On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></blockquote><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><br class="m_1627382426658515870Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">On Mar 23, 2017, at 8:27 PM, Drew Crawford <<a href="mailto:drew@sealedabstract.com" class="gmail_msg" target="_blank">drew@sealedabstract.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Sent from my iPhone</div>On Mar 23, 2017, at 6:41 PM, David Hart <<a href="mailto:david@hartbit.com" class="gmail_msg" target="_blank">david@hartbit.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">I have difficulties imagining a submodule proposal that could allow us to eliminate fileprivate. Care to give an example?</div></blockquote><br class="gmail_msg"><div class="gmail_msg">The obvious example would be Rust. Rust has exactly two visibilities, and merely one keyword. By default, members are "private" which is visible inside the module (so, like Swift's internal). The "public" keyword is similar to Swift. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The reason this works is that unlike in Swift where a module is something like a library or framework (Rust calls those "crates"), in Rust modules in are (explicitly) lexically scoped; a "mod myscope {}" module can be created for the portion of the file for which the member should be visible and it won't be visible outside that scope. Likewise, "fileprivate" can be achieved by enclosing the file in a "mod MyFile {}". And like all lexical scopes, they can be recursively nested to arbitrary depth to achieve any number of visibility behaviors (e.g., declare a module for the first half of two files) that would require complex new keywords to achieve in Swift.<span class="m_1627382426658515870Apple-converted-space gmail_msg"> </span><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">Finally there are some shortcut features like the ability to infer a module structure from the file system. </span></div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><br class="gmail_msg"></div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="gmail_msg">This is a good example of what I meant. There is an extremely broad range of possible designs for submodules. Some of them, such as this example, would make it relatively easy to get by without fileprivate. There are also many other possible designs that would not. </span><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">We do not have any idea where Swift will end up yet. It's not reasonable to make any assumptions about what use cases the eventual design might or might not address.</div></div></blockquote></div><br class="gmail_msg"></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">Then why not leave private and fileprivate alone until we do?</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Charles</div><div class="gmail_msg"><br class="gmail_msg"></div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>