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

[Jordan Rose]

> On Jan 11, 2016, at 20:33 , Félix Cloutier via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> This is the reply that I wrote to someone else who wanted a private(extension) <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005450.html> 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.
> 
> 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.

This is not the recommended way to think about Swift access control, and it is not guaranteed. For example, an overridable internal method in a publicly-subclassable class currently needs to appear in a subclass's vtable, even if the subclass is in another module and cannot possibly override this method. That's an implementation detail, sure, and it isn't a long-term constraint (because we want you to always be allowed to add new methods), but it's an example of a case where symbol linkage doesn't match up with access control.

Access-control-related features should be evaluated on their own merits, not on the implementation details of exported and non-exported symbols.

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160112/3dd85965/attachment.html>