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

[Félix Cloutier]

To be clear, I agree that there is a problem. I just perceive it as a documentation problem more than as an access control problem.

There are at least 2 other proposals that suggest(ed?) a more complex access control model (`private(extension)`, `private(objc)`), and I don't like adding exceptions to `private`.

Félix

> Le 12 janv. 2016 à 16:43:39, Charles Srstka via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160112/ff10bdc6/attachment-0001.html>