<div dir="ltr"><b>@Daniel</b><div>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>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><br></div><div>Current:</div><div>fileprivate(set)</div><div><br></div><div>Suggested:</div><div>private(file)(set)</div><div><br></div><div>Still, of all the hurdles one might face, this one I believe is definitely the one that poses the less threat!</div><div><br></div><div><b>@Tino</b></div><div>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&#39;s evolution into finer grained control and better focused levels of scope. Quoting Álvaro: <span style="font-size:12.800000190734863px"> &quot;</span><span style="font-size:12.800000190734863px">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.&quot;</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Also Tino, you state:</span></div><div>&quot;<span style="font-size:12.800000190734863px">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">&quot;private, internal, public&quot; was quite simple, but the current system is already quite complicated, and it doesn&#39;t scale well.&quot;</div><div><br></div><div>In fact, I consider this change a great opportunity for the current system to be revisited in a gradual manner.</div><div>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><br></div><div>There&#39;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&#39;r all sitting within the same file. This creates conditions for a odd and dangerous pattern. While I don&#39;t think fileprivate aims at promoting several type implementation within the same file, it certainly opens that door. That&#39;s one pattern a typeprivate access control level would grant no advantages in using.</div><div><br></div><div>Best,</div><div>Gonçalo</div></div>