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

[cocoadev at charlessoft.com]

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.

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.

>> 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.
> 
> Sure, but `init` and `deinit` in Swift are function-like constructs
> that aren't quite functions in order to accommodate all this. Surely
> you don't want to go that far here.

Under the hood, they're just methods; if your class derives from 
NSObject, you can even inspect it with the Objective-C runtime 
functions. It's just that they have special semantics for calling them.

Charles