<div dir="ltr">My two cents:<div><br></div><div>I like that Swift has a way of restricting access to some properties and functions to just the scope in which they're declared (Swift 3 private).</div><div><br></div><div>At the moment I tend to use the Swift idiom of declaring a type, and then declaring an extension each protocol conformance, and sometimes that means putting a property in the type rather than the extension and that requires fileprivate. That's not ideal, but if there were an idiomatically neater way to declare a private property in the extension and have Swift recognise that property as being part of the type but contextually linked only to that protocol conformance then that would be good.</div><div><br></div><div>'Fileprivate' makes files equivalent to submodules, and this can lead to undesirably long files. Possibly the dependence on filesystem structure feels restrictive to some developers. It seems to me that in this four-tier structure (public, internal, fileprivate, private) that a significant number of developers think that's one, maybe two tiers too many (the system should be simplified), and for others that's one, maybe two tiers too few (fileprivate is doing too much, and a submodule tier would relieve that pressure).</div><div><br></div><div>I think a submodule access level has been suggested a lot of times, but I don't think anyone's formally proposed a possible syntax for it.</div><div><br></div><div>As Goffredo Marocchi said, I don't want to return to Objective C's dozen import statements at the top of a file, but how would we denote that a file is a member of a submodule? At the moment I think there are four ways - have I missed any?</div><div><br></div><div>1) Submodules correspond directly to file directories (simple, but possibly binds a project too closely to an operating system, inflexible for systems like Git).<br></div><div>2) The submodule has an access control file which lists its member files (as modules do)</div><div>3) Files opt-in to membership of a submodule (e.g. 'memberOf Submodule' just below 'import Foundation')</div><div>4) Files 'friend' other files into their submodule, somehow.</div><div><br></div><div>Worth noting: the latter three of these suggestions don't implicitly prevent a file from being a member of more than one submodule.</div><div><br></div><div>I don't have my own answer to this question yet, but I think discussion of it will help decide whether submodules are a practical possibility. If they are, perhaps there's justification for fileprivate; if not, perhaps reverting to Swift 2's private is better.</div><div><br></div><div>Thanks,</div><div>Ross</div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 20, 2017 at 10:41 AM, Dimitri Racordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><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>I really don’t like the idea of an attritional access control file.</div>
<div><br>
</div>
<div>Not everybody is using an IDE that automagically creates the structures and files for your favourite language, and I would hate to see Swift go the Java way where it’s impossible to build something seriously without Eclipse or Netbeans. Xcode
is great, but I think we should not design Swift thinking it’s the norm to use it.</div>
<div><br>
</div>
<div>I’d favourite any kind of syntax that is baked in the same file as the code.</div>
<div><br>
</div>
Thanks,<br>
<div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">
Dimitri</div>
</div>
</div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>