[swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

[Xiaodi Wu]

On Sat, Apr 15, 2017 at 12:50 PM, Dave DeLong <delong at apple.com> wrote:

> 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 *everything* 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.
>

To be clear, I'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't happen. I'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.

(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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170415/0cebecb5/attachment.html>