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

[cocoadev at charlessoft.com]

On 2016-01-12 13:50, Michel Fortin wrote:
> Le 11 janv. 2016 à 19:53, Charles Srstka via swift-evolution
> <swift-evolution at swift.org> a écrit :
> 
>> What do you think?
> 
> The idea looks good to me on the surface. But the details are awkward.
> 
> First, if you can't call the super implementation from an override,
> there is no need to require that the overriding function be
> private(call) because all it will contain is client code that can't
> call the library's implementation. So the derived class can make the
> function more visible by reimplementing it.

My thinking is that if the subclass wants to make the functionality 
behind the method more visible, it's better to just spin it off into a 
separate method rather than ask callers to get used to calling a method 
that, according to the API contract of the superclass, is more an 
implementation detail than a part of the external interface.

> But that's not the common case. In general you want to allow the
> overriding function to call the super implementation. So...
> 
> Second, if you allow a call to the super implementation from an
> override, then you need to make that overriding function uncallable by
> anyone. Only the base class can call it using virtual dispatch. You
> can't call it even from the same file, so it's *less visible than
> private*.
> 
> That's a bit weird.

It may be a bit weird, but it is what the API contract is already asking 
the class to do. It's just that currently, it's not enforced other than 
in documentation.

I should point out that we, essentially, already have methods like this; 
Swift initializers, unlike init methods in Objective-C, are similarly 
invisible; they cannot be called by any other code, even in the same 
file, unless that code is marked as a convenience initializer. Deinit, 
likewise, can't be called by anything except for the Swift runtime 
itself.

Charles