<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="">On 8 Oct 2016, at 20:01, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" 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=""><span class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 8 Oct 2016, at 16:47, Braeden Profile <<a href="mailto:jhaezhyr12@gmail.com" target="_blank" class="">jhaezhyr12@gmail.com</a>> wrote:</div><br class="m_3837719418597257116Apple-interchange-newline"><div class=""><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=""><blockquote type="cite" class=""><div class=""><br class="">On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_3837719418597257116Apple-interchange-newline"><div class=""><div style="word-wrap: break-word;" class="">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=""><br class=""></div><div class="">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=""><br class=""></div><div class="">Yes, but “protected" 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=""><br class=""></div><div class="">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=""></span><div class="">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=""><br class=""></div><div class="">I'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't be refactored into a module of its own? As mentioned by Matthew, isn't this calling for some notion of submodules?</div></div></div></div></div></blockquote><br class=""></div><div>I'm implementing NSDecimal in Swift and it uses fileprivate to wrap up scope for internal implementation details. The implementation that I've got on my GitHub account is currently at 885 lines; but I'm still working on other parts and my currently checked out version has 1125 lines of code, in a single file.</div><br class=""><div class=""><a href="https://github.com/alblue/swift-corelibs-foundation/blob/nsdecimal/Foundation/NSDecimal.swift" class="">https://github.com/alblue/swift-corelibs-foundation/blob/nsdecimal/Foundation/NSDecimal.swift</a></div><div class=""><br class=""></div><div class="">Submodules aren't the right answer here, because Foundation as a while is a module that won'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=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Alex</div></body></html>