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

[cocoadev at charlessoft.com]

On 2016-01-12 22:18, Michel Fortin wrote:

> I realize I was probably mistaken by an example that was not written
> by you but by Félix Cloutier. If you were the one that wrote this
> example in the thread then my criticisms would apply:
> 
> class A {
> 	private(call) func logicYouShouldImplementButNotCall() {
> 	}
> }
> 
> /* other module */ class B {
> 	private(call) override func logicYouShouldImplementButNotCall() {
> 		iActuallyWantToCallItWhyWontYouLetMeDoIt()
> 	}
> 
> 	func iActuallyWantToCallItWhyWontYouLetMeDoIt() {
> 		/* snip */
> 	}
> }
> 
> In this example, class B is qualified `private(call)`, but it can't be
> made private here (nor internal or public), because it has to be less
> visible than any of those. (Actually, to confuse things further it
> could because it does not call the super implementation, but let's
> ignore that for now.)

The class B isn't qualified 'private(call)', but rather just the method 
it's overriding. The method itself would probably need to be 
private(call) as well, because Swift requires methods to be at least as 
visible as the original methods from a superclass or protocol. This bugs 
me, actually, since it causes your class interface to be cluttered up by 
stuff required for protocol conformance that could have been happily 
left out of the header file in Objective-C, with callers still knowing 
that those methods were supported due to their being present in a 
protocol that the class implements, or in a superclass. But that's a 
separate issue.

I'm still confused by how something you can override but not call could 
be considered less visible than something you can't override, call, or 
even see.

> 
>> 2. How this means that you can't mandate private(call), or that it 
>> would be "a lie", simply confuses me.
>> 
>> 3. "You can override this but you can't call it" isn't too complicated 
>> to wrap one's head around, and to my mind sums up this feature pretty 
>> succinctly.
> 
> The question is: what is the syntax at the override point? I
> mistakenly thought it'd require `private(call)` because I saw this
> example, but there's actually nothing about that in the initial
> proposal.
> 
> Sorry for the confusion.

Well, Swift's existing rules state that the overriding method needs to 
be at least as visible as in the superclass, so private is already out. 
Whether you can change it to internal or public depends on whether you 
feel that it should be possible to make a primitive method more visible 
and have people calling it. Personally, my thought on the matter is that 
if you want to expose that functionality, it's better to spin it off 
into a separate method as Félix did, but you could argue either way on 
that, I suppose.

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.

Charles