On 30 October 2017 at 22:38, Adam Kemp <adam_k...@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution