This discussion has been had on this list several times already. Using a name other than fileprivate, in particular, was part of the original discussion and the core team selected the current spelling.<br><br>As Tino mentioned, submodules are a topic that the community has already expressed some interest in incorporating in the future and is listed as a possible topic by the core team for Swift 4 stage 2. At that time, it would seem obvious that submodule access levels would be introduced. It seems that this idea would be largely duplicative of that functionality, and it would destroy the current deliberately chosen file-based design for access levels.<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 1, 2016 at 08:42 João David 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 dir="auto" class="gmail_msg"><div class="gmail_msg">@Daniel, agree.</div></div><div dir="auto" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Sent from my iPhone. Erroneous words are a feature, not a typo.</div></div><div dir="auto" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">On 1 Dec 2016, at 14:23, Daniel Leping <<a href="mailto:daniel@crossroadlabs.xyz" class="gmail_msg" target="_blank">daniel@crossroadlabs.xyz</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div style="white-space:pre-wrap" class="gmail_msg">Gonçalo, I can suggest a bit different API to avoid clashing. Something like:<br class="gmail_msg"><br class="gmail_msg">private (file, set)<br class="gmail_msg"><br class="gmail_msg">Instead of:<br class="gmail_msg"><br class="gmail_msg">private (file) (set)<br class="gmail_msg"><br class="gmail_msg">Looks easier to me as it poses a possibility just to list the attributes in a pretty much standard way.</div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Thu, 1 Dec 2016 at 16:15 Gonçalo Alvarez Peixoto 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"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><b class="gmail_msg">@Daniel</b><div class="gmail_msg">I am very fond of your idea, as I believe it add extra flexibility to this solution, as Álvaro mentioned. My only concern is somehow related to semantics.</div><div class="gmail_msg">Should we add the extra scope detail as you suggest, then it could clash with the current way of setting a setter as private or fileprivate:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Current:</div><div class="gmail_msg">fileprivate(set)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Suggested:</div><div class="gmail_msg">private(file)(set)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Still, of all the hurdles one might face, this one I believe is definitely the one that poses the less threat!</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><b class="gmail_msg">@Tino</b></div><div class="gmail_msg">As you imply on a previous email, this solution might even facilitate the introduction of new levels of access control all throughout modules, whether internally and externally. While I do agree complexity does raise an issue in designing a fine solution for access control, I insist this concern should not block the language's evolution into finer grained control and better focused levels of scope. Quoting Álvaro: <span style="font-size:12.800000190734863px" class="gmail_msg"> "</span><span style="font-size:12.800000190734863px" class="gmail_msg">communication is something that everyone agrees is a essential in swift and access control is one of the many ways developers have to properly describe (and communicate) an API."</span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg">Also Tino, you state:</span></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg">"<span style="font-size:12.800000190734863px" class="gmail_msg">The question for me is how much complexity should be accepted as a tradeoff for increased expressiveness?</span></div><div style="font-size:12.800000190734863px" class="gmail_msg">"private, internal, public" was quite simple, but the current system is already quite complicated, and it doesn't scale well."</div><div class="gmail_msg"><br class="gmail_msg"></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg">In fact, I consider this change a great opportunity for the current system to be revisited in a gradual manner.</div><div class="gmail_msg">As to the equatable issue you pointed out, is there a reason why replacing the fileprivate access control level by with a typeprivate would not solve the problem raised with private?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">There's yet another issue I would like to reinforce, one raised on previous emails. As stated before, I do believe fileprivate, as a compiler related construct, opens the door for one to access members from another member, as long as they'r all sitting within the same file. This creates conditions for a odd and dangerous pattern. While I don't think fileprivate aims at promoting several type implementation within the same file, it certainly opens that door. That's one pattern a typeprivate access control level would grant no advantages in using.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Best,</div><div class="gmail_msg">Gonçalo</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>
</div></blockquote></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>