<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Ok, on this I can agree... and I will. It try to mention how judging things by how "Swifty" they are makes us seem like a cult... but then again we are programmers/engineers... that word may very well apply appropriately :).<br><br>Sent from my iPhone</div><div><br>On 20 Feb 2017, at 08:46, Jonathan Hull <<a href="mailto:jhull@gbis.com">jhull@gbis.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">I didn’t say we should have headers, I said we need something that maps to those use cases in a swift-y way.<div class=""><br class=""></div><div class="">Just being able to mark something as internal to the type, and a way to opt-in to seeing those things within a particular file.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 20, 2017, at 12:39 AM, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" class="">panajev@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Please, almost anything but going back to the horrible Objective-C pattern of private headers (that end up included on in the implementation files) :/.</div><div class=""><br class=""></div><div class="">Seriously, that was always my issue with that blog post, assuming that the Objective-C way of dealing with this issue was something worth moving forward and not a path to massively improve upon or to avoid.<br class=""><br class="">Sent from my iPhone</div><div class=""><br class="">On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 19, 2017, at 7:29 PM, David Waite 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 class="" 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;">A third point (which is a bit more complex/convoluted) is that fileprivate remained an essential language feature because it allows implementation in extensions, and allows a simple “friend”-like feature where types that need access to implementation details due to higher coupling could be bundled into the same file. Outside of a desire of a scoped ‘private’ simply to match the behavior of certain other languages, private is used to hide implementation details from other parts of a file, while file private exposes them within the file. </div><div class="" 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;"><br class=""></div><div class="" 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;">There is a potential that file-private can lead to an explosion of complexity due to a large amount of “friendly types” being bundled into the same file. In that sense, ‘private’ was wrong because it was adding complexity at the file level, when really a new access level would possibly have been more productive to define at the at the small-group-of-files level - either via a friend access level or submodules. We still have the potential of unmanageable files due to friend types, but any additional access levels to aid with this problem would have to be weighed against a now significantly more complex access model including file and scoped private. In that sense, the inclusion of scoped private may indeed be harmful in that it increases the challenge of much more useful access levels being added to the language.</div></div></blockquote></div><br class=""><div class="">This is the core of what I have been saying. If we don’t address this need of “friendly types” in a swift-y way, we will have to keep coming back to the drawing board (either for “friend” or “protected” or “submodules”). I really like swift 2 private, but it did cause long files because all of the extensions and friends had to be stuck in the same file. What we are really missing is something that has the connotation similar to private, but allows access where needed.</div><div class=""><br class=""></div><div class="">I agree with most of what was said in this blog post from the swift devs:</div><div class=""><a href="https://developer.apple.com/swift/blog/?id=11" class="">https://developer.apple.com/swift/blog/?id=11</a></div><div class=""><br class=""></div><div class="">The main exception is that I disagree that ‘internal’ maps to the ObjC case where a second header was used (it doesn’t, and that is what is causing all of this trouble). Because internal is the default, it feels much too easy to accidentally use parts of a type which should only be used by extensions/subclasses/friend types. Remember, in an app (as opposed to a framework), internal is basically equivalent to public. With the second header, users of the contents of that header had to explicitly include it, which meant there was no chance of accidental use.</div><div class=""><br class=""></div><div class="">What we need is something which maps to that second header case while still keeping everything conceptually simple and swift-y.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div><div class=""><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div></blockquote></body></html>