[swift-evolution] classprivate protection level?

[Mike Kluev]

On 30 October 2017 at 22:38, Adam Kemp <adam_kemp at apple.com> wrote:

>
> “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.
>

i still see a value in it:

- i do a search for, say, "foo" (all files in the module)
- let's say 50 usages will be legitimate use from within the class or it's
extensions
- another 10 usages will be wrong, that mistakenly treated it's "internal /
public" as a permission to use.
- i found those instances which shall not be there (that mistakenly use it
as it is effectively public)
- i ask developers who did it to not do this again / fix the problem / etc
- some time later i can do the same mistake myself again or other people
will do the same mistake again and the process repeats.
- compiler doesn't help as it can't check
- it becomes a manual and error prone process

"classprivate" helps to resolve this problem. if it is marked so developer
will at least think twice before making an extension to use it - similar to
how marking a method "protected" stops people from using it without
subclassing - (and creating an extension for the sole purpose of using
despite of it's access level would qualify as "cheating", which we can
leave aside). with "internal / public" there is nothing stopping them for a
second and they can use it without even realising they are doing something
wrong. all IMHO.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171030/7d1c4c62/attachment.html>