<div dir="ltr">On Sat, Apr 15, 2017 at 12:50 PM, Dave DeLong <span dir="ltr">&lt;<a href="mailto:delong@apple.com" target="_blank">delong@apple.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">While I appreciate the simplicity of such a statement, in reality it would be a step backward even from Objective-C and is not a practical design for anyone who works on a multi-person team. In Objective-C, members are selectively #import’d, so <i>everything</i> is “private” unless it’s #import’d. Since Swift takes the approach of implicit importation of the module, there’s no way to hide parts of functionality from other subsystems in your module without resorting to fragile and unsafe naming conventions (e.g.: “don’t use things that start with an underscore”). It would be a massive design mistake, for example, for every private method on every piece of code in UIKit to be exposed to every other client inside UIKit.</div></blockquote><div><br></div><div>To be clear, I&#39;m not suggesting that we should implement such a design (or even discuss it in this thread); the core team has made very clear that it won&#39;t happen. I&#39;m simply stating that, insofar as there are some people who wish for infinite granularity in access control--exemplified by this proposal--there are others who believe that in a perfect world we would distinguish only public API from non-public API. It goes without saying that, in such a world, there would need to be facilities for selective import.</div><div><br></div><div>(There are good reasons why one might need selective import facilities in Swift as it is today, such as in the case of conflicting definitions of operators, and there have been proposals which aim to solve this somewhat orthogonal issue which are certainly worthy of consideration.)</div></div><br></div></div>