[swift-evolution] classprivate protection level?

[Adam Kemp]

> On Oct 30, 2017, at 2:23 PM, Mike Kluev <mike.kluev at gmail.com> wrote:
> 
> On 30 October 2017 at 19:49, Adam Kemp <adam_kemp at apple.com <mailto:adam_kemp at apple.com>> wrote:
>  
> How do you know there’s not an extension in this file without looking? If you don’t know then you have to check. That puts it in the same bucket as internal or public. The set of files you have to search through for usages is the same.
> 
> 
> I'd just search for "extension SomeClass", Xcode search result window will list all files that have it.
> or I will list all the users of "foo" if that's the one I am changing.

When you do that search, which files do you include in the search? That’s the key.

> 
> the good guideline from Obj-C was (and still is) using "SomeClass+ExtensionName" file naming convention that also helps.

That’s not sufficient because there’s nothing in the language that would force people to follow this convention, and you can have extensions in any file for any class.

The point I’m trying to make, again, is that the set of files that you would have to search through is the same. Once you know the set of files that need to be searched you can just search for actual usages of the API you’re changing (the method or property or whatever). The important thing is to know which files need to be searched in the first place. That’s what access level really controls.

Each access level implies a unique set of files that have to be searched. Public = all files in all clients. Internal = all files in this module. File private = just one file. Private = just one part of one file.

“specialprivate", by allowing any extension to access the API, would imply the same set of files as either internal or public. You can’t know ahead of time whether some random file in your module might make an extension that access that API so you have to search all files within that module. You would perform the search exactly the same way. It doesn’t help you as a library maintainer. You’re not going to save work by making something “specialprivate” instead of internal. Worst case is you actually convince yourself that you don’t have to search the whole module, and then you break something because of that misunderstanding. That’s why internal is better. It avoids obfuscating the actual implications of that access level.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171030/8e65d12c/attachment.html>