[swift-evolution] private(call) and internal(call)

[cocoadev at charlessoft.com]

On 2016-01-11 23:33, Félix Cloutier wrote:
> This is the reply that I wrote to someone else who wanted a
> private(extension) [2] modifier. Swift's access modifiers align with
> linker access modifiers and visibility styles: `private` is not
> exported beyond the translation unit (and can be very aggressively
> optimized), `internal` is hidden (not exported to the dynamic symbol
> table) and `public` is exported to the symbol table of the resulting
> executable. `Private(set)` just means that the setter method is not
> exported but the getter is.
> 
> So as I said in the other thread, I wouldn't consider that these new
> modifiers follow the example that private(set) set.

Okay, amend that statement to say that it follows the _syntactic_ 
example of private(set). How it is implemented under the hood is just 
that: implementation details.

> The great thing about using the linker to implement access control is
> that it can be enforced. The reason internal or private can't be
> called from outside an executable is that no data about it exists in
> the final executable As a matter of fact, the symbol itself might not
> even exist in the fully optimized executable.

Access modifiers aren't just across linker boundaries. Private, 
private(set), and, if implemented, private(call) would help enforce 
boundaries between classes within a single module as well.

> I also think that it's fundamentally the same as protected, because
> nothing prevents you from sharing the logic outside. You can forward
> the protected call to a public call, which is exactly the same as a
> public call forwarding to a protected call in terms of encapsulation.

Um, if that's your metric, then private is fundamentally the same as 
internal is the same as public, and there's no such thing as access 
modifiers at all. *Anything* can be forwarded to a public call, whether 
it's private, public, internal, my proposed private(call), or protected, 
if it's done within the class that owns it. However, code from outside 
the class (or struct, or enum, or whatever) wouldn't be able to access 
something defined as private(call), even if it's a class and they're a 
subclass of it, whereas with protected, if you're a subclass it's 
basically open season.

Charles