<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 1 déc. 2016 à 18:54, Gonçalo Alvarez Peixoto via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">@Aron, I did take a look at that document while developing the proposal. As you stated, it's a little old, however the principles of access control and their purpose remain pretty much the same.&nbsp;<div class=""><br class=""></div><div class="">".keep private details of a class hidden from the rest of the app</div><div class="">&nbsp;.keep interna details of a framework hidden from the client app"</div><div class=""><br class=""></div><div class="">Both these rules still get respected with the introduction of a new level of access control.&nbsp;<b class="">typeprivate&nbsp;</b>would not allow for member access within any other then the&nbsp;<b class="">type</b>&nbsp;itself.</div></div></div></blockquote><div><br class=""></div><div>typeprivate is confusing. Would we allow access to extension in the same file, in the same module, everywhere ?&nbsp;</div><div><br class=""></div><div>If a ‘typeprivate’ is accessible anywhere, it look more like a public var than a private one.</div><div><br class=""></div><div>Maybe we should also introduce a typeinternal and typepublic modifier in such case to explicitly define who can access the var.</div></div><br class=""></body></html>