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

Michel Fortin michel.fortin at michelf.ca
Tue Jan 12 22:16:46 CST 2016

Le 12 janv. 2016 à 22:52, cocoadev at charlessoft.com a écrit :

> In any case, the most common use case, and the one that IMO makes the most sense, would be to define the overriding method as private(call) as well.

Ok then, that's the lie. (Not that you're lying, but the syntax you propose is a lie.)

When I read `private(call)`, I read it "private visibility for calling the method", just like `private(set)` means "private visibility for the setter". A private visibility limits the usage to the current file. And the usage being limited to the current file is the ability to call the method.

When you apply `private(call)` in the base class context, the method is callable only from the current file (thus the call ability is private). That's exactly what's needed. All is good.

But when you apply `private(call)` at the override point, you want the method to not be callable from the current file. The syntax is saying the call ability is private (limited to the current file), but that's simply not true. What you really want to say here is `unavailable(call)`, but that does not exist.

Michel Fortin

More information about the swift-evolution mailing list