> On Oct 29, 2017, at 5:29 PM, Mike Kluev <mike.kl...@gmail.com> wrote: > >> On 29 October 2017 at 16:04, Adam Kemp <adam.k...@apple.com> wrote: >> Internal is the right choice here. If it gives too much access then you >> might consider pulling this code into a separate module. >> >> If “private” gave access to every extension then any code outside your >> module could make a new extension and access that method. That would make it >> effectively public in that you wouldn’t have any ability to limit who can >> call it. >> > > there are two very different use cases for which we use extensions. > > 1) the extensions i use to split implementation of my own classes into > different parts and / or files. for the sake of this discussion let's call > this type of extensions a "continuation".
Internal is sufficient for this use case. > > 2) the extensions that are used to extend other people classes or system > classes. this matches what we have now. There’s no need for a new access level here. If it’s in the same module then you use internal. If it’s not then you shouldn’t be able to access anything other than public API. > > speaking of (1) the naïve newcomers from C++ land would consider these > continuations the same as splitting their C++ class implementation into > separate files. e.g. the expectation is having an ability to access "private" > members. if such a thing existed in swift at all it wouldn't be unimaginable > having an ability to add variables in these continuations the same way as in > the class itself. here "protected" access level would be a reasonable > addition, and if we want to be totally nitpicky "protected" would be for > subclasses and some other keyword, say, "extensionprivate" or "domestic" for > continuations. Protected is a different concept entirely. I’m not sure what the reasoning was for leaving it out. Personally I do think protected is a useful access level so that you can clearly define API intended for subclasses. However, protected has nothing to do with extensions. It doesn’t solve that use case. > > an interesting challenge would be somehow prohibiting external people adding > continuations to your own classes :) That was my original point. This is what internal does. We don’t need any new access levels for extensions. Internal solves these use cases. Code in the same module can be maintained in lockstep so you can make things internal as needed for extensions. Anything beyond that is effectively indistinguishable from public so just call it that. > > Mike >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
