<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><div><br></div></span><div>This is what I had in mind; i.e- you don&#39;t <b>have</b> to parameterise private, you&#39;d only do it if you want something other than the default.</div><div><br></div><div>As for something with both public and private modifiers (only really applies to properties I think?) I think it&#39;s fine to just declare each separately, as there may in future be more public parameters so it makes sense to have the separate grouping of a property&#39;s public and private components.</div><div><br></div><div>I&#39;m not clear on your use of private(type:module), what do you see that as representing? Personally I&#39;d just expect them to be used like private(module, type), i.e- the method/property is private but accessible by both module and (externally) by sub-classes.</div><span class=""><div><br></div></span></div></div></blockquote></div><br></div><div class="gmail_extra">Does &#39;private(module, type)&#39; grant get-set access to external subclasses, or get-only?</div><div class="gmail_extra"><br></div><div class="gmail_extra">If I write &#39;private(file, type)&#39; is the property accessible only to types within the module, or outside as well?</div><div class="gmail_extra"><br></div><div class="gmail_extra">The &#39;type&#39; axis (which includes the &#39;protected&#39; concept) is related to the &#39;module&#39; axis (which includes &#39;internal&#39; and &#39;fileprivate&#39;) and the &#39;get set&#39; axis. Perhaps not strictly orthogonal, but still three dimensions. If Swift is to add a type axis, we should be careful not to think of it as simply additional states on the &#39;module&#39; axis.</div><div class="gmail_extra"><br></div></div>