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

Michel Fortin michel.fortin at michelf.ca
Tue Jan 12 21:18:32 CST 2016

> Le 12 janv. 2016 à 21:46, cocoadev at charlessoft.com a écrit :
> On 2016-01-12 17:34, Michel Fortin wrote:
>>> 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.
>> What I meant here is that you can't even mandate `private` at the
>> override point because it's *less visible than private*. So writing
>> `private` or `private(call)` at the override point is a lie. You can't
>> define `private(call)` to mean "private access for calling this but if
>> there is a override keyword next to it then it means less visible than
>> private and you can't call it", that's too awkward.
>> I understand what the API contract is, but all I'm saying is that I
>> wonder if there is a syntax that can express all this sanely.
> I've read this paragraph a large number of times, and I still don't understand what the objection is here.
> 1. It's not less visible than private, it's more visible by definition, because it appears in the interface and you can interact with it (by subclassing a class or implementing a protocol). If it were just plain private, it would be completely invisible and there would be no way to interact with it or even see that it exists outside of hacky things.

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() {
	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.)

> 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.

Michel Fortin

More information about the swift-evolution mailing list