[swift-evolution] private(call) and internal(call)
nevin.brackettrozinsky at gmail.com
Tue Jan 12 22:33:30 CST 2016
I am not an expert, but if we were to do anything along these lines at all,
wouldn’t it make more sense to have something like @warn_on_call with which
to annotate functions/methods that should never be called from client code
but may need to be overridden? IDE’s could hide those items from
On Tue, Jan 12, 2016 at 11:16 PM, Michel Fortin via swift-evolution <
swift-evolution at swift.org> wrote:
> Le 12 janv. 2016 à 22:52, cocoadev at charlessoft.com a écrit :
> > 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
> Ok then, that's the lie. (Not that you're lying, but the syntax you
> propose is a lie.)
> When I read `private(call)`, I read it "private visibility for calling the
> method", just like `private(set)` means "private visibility for the
> setter". A private visibility limits the usage to the current file. And the
> usage being limited to the current file is the ability to call the method.
> When you apply `private(call)` in the base class context, the method is
> callable only from the current file (thus the call ability is private).
> That's exactly what's needed. All is good.
> But when you apply `private(call)` at the override point, you want the
> method to not be callable from the current file. The syntax is saying the
> call ability is private (limited to the current file), but that's simply
> not true. What you really want to say here is `unavailable(call)`, but that
> does not exist.
> Michel Fortin
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution