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

[cocoadev at charlessoft.com]

On 2016-01-12 23:16, Michel Fortin wrote:
> 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.

Ah, I see what you're saying, that the private(call) in B implies that B 
can call it. It's a semantic issue. Well, if you want to have the 
subclass's implementation declared as unavailable(call), that works.

Charles