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

[Nevin Brackett-Rozinsky]

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

Nevin

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
> well.
>
> 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
> https://michelf.ca
>
> _______________________________________________
> 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/d8205ea6/attachment.html>