<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>@Daniel, agree.<br><br>Sent from my iPhone. Erroneous words are a feature, not a typo.</div><div><br>On 1 Dec 2016, at 14:23, Daniel Leping <<a href="mailto:daniel@crossroadlabs.xyz">daniel@crossroadlabs.xyz</a>> wrote:<br><br></div><blockquote type="cite"><div><div style="white-space:pre-wrap">Gonçalo, I can suggest a bit different API to avoid clashing. Something like:<br><br>private (file, set)<br><br>Instead of:<br><br>private (file) (set)<br><br>Looks easier to me as it poses a possibility just to list the attributes in a pretty much standard way.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, 1 Dec 2016 at 16:15 Gonçalo Alvarez Peixoto 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="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></body></html>