<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 Jun 28, 2016, at 01:14, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello everybody,<div class=""><br class=""></div><div class="">I tried using the access rules defined in SE-0025 in some code of mine to see what effect it would have. I came out of the experiment more disappointed than I thought. Here are several reasons:</div><div class=""><br class=""></div><div class="">1) The new rules make `private` more prominent compared to `fileprivate` (the latter has a somewhat worse name). But at the same time, the Swift community has developed a style of coding where a type is defined through a set of extensions. To hide members from other types, but have access to them inside the type extensions, we have often used `private` and placed the type and its extensions in the same file. Because `private` is scoped, we are forced into using `fileprivate` pervasively (which is uglier), using `internal` instead (which is less safe) or moving the extension code into the type's scope (which is against the way Swift code is being written today). All of these options look worse to be than before SE-0025.</div><div class=""><br class=""></div><div class="">2) The new amended rules look complicated to me. I think they have the risk of being confusing in practice, but we’ll have to see.</div><div class=""><br class=""></div><div class="">More generally, I think that the scoping rules of `fileprivate` may have an in insidious effect that favour moving code back into the type’s scope instead of preferring the cleaner style of putting it into extensions.</div><div class=""><br class=""></div><div class=""><b class="">Potential solution:</b></div><div class=""><br class=""></div><div class="">What is `private` members were also visible to all extensions of the type in the same module?</div></div></div></blockquote><br class=""></div><div>I am strongly against this. Swift uses scope-based privacy; the new ‘private’ is still scope-based. Type-based privacy encourages extensions where none are needed and the right answer was ‘fileprivate’.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>