[swift-evolution] access control proposal

[Ilya Belenkiy]

As soon as we say that we need to allow access for performance, scope or
local is not applicable. For that, private is perfect. But it should be a
rare exception and an alarm for anyone reading the code that the API
invariant could be broken by something else in the file. Most APIs don't
need this and should completely hide their implementation details. Local is
for that case. Distinguishing these cases helps clarifying the intent for
whoever is reading the code. The most important part though is that the
compiler enforces that intent.

--
Ilya Belenkiy

On Mon, Dec 14, 2015 at 11:52 AM David Owens II <david at owensd.io> wrote:

> Let’s take this it’s next logical conclusion: I have two types that need
> to access each other’s members for some significant performance gain. Let’s
> call these types A and B. Now, A also needs access to the inner members for
> C for the same reason (but note that B does not). I currently have other
> related types all in the same file, let’s say D and E.
>
> Now, all members should be “local” to the types, but remember, A needs to
> access B's and C's members and the other types do not. Also, I can’t simply
> move the them to different files because they have non-overlapping “local”
> usage requirements. So do I need to create a “local friend” modifier so
> only particular types can access the inner details?
>
> There’s a line somewhere where complexity becomes more burdensome. I’m not
> sure if “local” is that line, but I absolutely do know that “local friend”
> is across that line (because of course we’ll need private friend and
> internal friend modifiers as well…).
>
> I imagine physical layout like this is not uncommon in Swift code.  This
> does not necessarily mean you want these extensions to see implementation
> details of each other.  By adding a ‘scope’ access modifier we are able to
> properly hide these implementation details regardless of physical layout.
>
>
> As mentioned above, what if you only want to make them available to *some* of
> the extensions?
>
> -David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151214/97620137/attachment.html>