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

[cocoadev at charlessoft.com]

On 2016-01-12 01:36, Félix Cloutier wrote:

> They're not, because as the writer of the Swift library, *you* are in
> control of internal and private members. I believe that the worry has
> never been what you could do with your own code, but rather what
> others can do with your own code, and in the case of a `private(call)`
> member, if the person really wants that logic to be callable, they
> have means to do it (whereas they don't have the means to call an
> internal or private symbol).

Unless we are talking about someone hacking their way in via C or 
assembler or something, no, they don't have the means to do so. And if 
we *are* talking about hacking, then that's impossible to prevent, 
anyway, if someone is *really* determined. I mean, even if the stupid 
thing is inlined, you could still disassemble the thing and 
copy-and-paste out the relevant part. Making things 100% bulletproof is 
not the goal, and if it were, we would have been publishing every single 
API, private and public, in Objective-C, since in that language it was 
staggeringly easy, even for a relative neophyte, to find and call 
private methods on pretty much anything. Despite that, we still found it 
useful to hide things in private headers and implementation files, which 
suggests that access control does have a use beyond the linker level 
after all.

> The only un-abusable justification for the feature is to document that
> a symbol shouldn't be used directly, hence the suggestion to use
> documentation features to achieve that goal.

It has multiple goals:

1) To document that it shouldn't be called directly

2) To keep it from being called accidentally via code completion

3) To make it enough of a PITA to call that people will be more likely 
to just do things the right way.

Charles