I don&#39;t find this example persuasive, because:<br><br>1125 LOC is on the long side for a single file, but not by any means &quot;thousands&quot; of LOC.<br><br>In any case, having hacked on corelibs-foundation myself, my sense is that its files are organized in such a way that NSDecimal would be expected to be implemented in a single file regardless of length.<br><br>If Swift had submodules, there&#39;s no reason to say that Foundation wouldn&#39;t make use of them to organize its types.<br><br>Even if you wished to share implementation details between, say, a hypothetically split up NSDecimal and Decimal, fileprivate members of NSDecimal could simply be internal instead, as is done elsewhere in corelibs-foundation. Note by comparison that, for implementation reasons, stdlib doesn&#39;t use fileprivate scope and all implementation details are internal or even public and underscored. A compelling argument for more fine-grained controls here would demonstrate how internal scope in stdlib or corelibs-foundation actually led to a bug that could have been prevented--I don&#39;t think any such bug exists.<br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 10, 2016 at 04:30 Alex Blewitt &lt;<a href="mailto:alblue@apple.com">alblue@apple.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 8 Oct 2016, at 20:01, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_2577396009407464475Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution<span class="m_2577396009407464475Apple-converted-space gmail_msg"> </span><span dir="ltr" class="gmail_msg">&lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt;</span><span class="m_2577396009407464475Apple-converted-space gmail_msg"> </span>wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 8 Oct 2016, at 16:47, Braeden Profile &lt;<a href="mailto:jhaezhyr12@gmail.com" class="gmail_msg" target="_blank">jhaezhyr12@gmail.com</a>&gt; wrote:</div><br class="m_2577396009407464475m_3837719418597257116Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_2577396009407464475m_3837719418597257116Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg">I was thinking that the domains themselves could be associated with a domain, so you could create alternate domains which are also publicly-visible, but distinct from the default, “public” domain.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">For example, if you have a bunch of methods which should be visible to subclasses, but you don’t want them to clutter your regular interface. Perhaps they have names which are confusingly-similar to the public API. I believe that is what “protected” is typically used for.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Yes, but “protected&quot; was specifically put down by the core team, seeing that any code from outside the library should see the class as one well-designed whole, not something with complicated, visible implementation details.  If your class-internal methods are confusing (and aren’t necessary for normal use), they shouldn’t be made public in any way.  Subclasses would too easily confuse the distinction between your implementation methods and your public ones.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">For what it’s worth, I was only confused by “private” and “fileprivate” for a minute or two until I looked up the actual proposal.  I haven’t had trouble with it, and it does actually provide more flexibility for code access at the file level than we had before.  Even if the syntax is clunky.</div></div></div></blockquote></div><br class="gmail_msg"></span><div class="gmail_msg">I’m not saying that (file)private is confusing - it’s very clear about what it does. But it is limiting; anything that wants access to those semi-private details needs to live in the same file. That’s clearly not scalable. Enormous files many thousands of lines long are easy for the compiler to digest, but less easy for humans to understand and navigate. In fact, I believe this whole “file-based” access control originally came out of the compiler’s implementation details.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I&#39;m interested in more information about this. What sorts of code have you been writing where a file would have to be thousands of lines long in order to accommodate `fileprivate`? Many entire modules are only thousands of lines long--is there a reason this code couldn&#39;t be refactored into a module of its own? As mentioned by Matthew, isn&#39;t this calling for some notion of submodules?</div></div></div></div></div></blockquote><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">I&#39;m implementing NSDecimal in Swift and it uses fileprivate to wrap up scope for internal implementation details. The implementation that I&#39;ve got on my GitHub account is currently at 885 lines; but I&#39;m still working on other parts and my currently checked out version has 1125 lines of code, in a single file.</div><br class="gmail_msg"><div class="gmail_msg"><a href="https://github.com/alblue/swift-corelibs-foundation/blob/nsdecimal/Foundation/NSDecimal.swift" class="gmail_msg" target="_blank">https://github.com/alblue/swift-corelibs-foundation/blob/nsdecimal/Foundation/NSDecimal.swift</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Submodules aren&#39;t the right answer here, because Foundation as a while is a module that won&#39;t be split apart. And for performance reasons, you want the internal functions (defined fileprivate) to be considered as eligible for optimisation by the compiler in the absence of (say) whole module optimisation.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Right now, the only way to do that is to have the fiileprivate implementations in the same file as the rest of the implementation.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Alex</div></div></blockquote></div>