[swift-evolution] classprivate protection level?

[Noah Desch]

Even if separating code into modules was an effortless process “internal" would still not be the right access modifier because you would have to make a sub-module for every class in a class hierarchy which defined new “protected” members. So we would need some near-effortless process for creating modules, and sub-modules would also have to be introduced to the language before we approach the functionality of a “protected” scope. I get that organizing all access around modules is conceptually simple (and thus tempting) but in practice I think it would be a huge PITA. 


> On Oct 29, 2017, at 3:36 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> You’re not really missing an other access modifier here. I assume you’re speaking about a macOS/iOS app, right? Therefore the thing you’re really missing is a full integration of SPM in Xcode macOS/iOS projects and submodules. Then, and only then `internal` would really seem like the right choice, because the rest of the app won’t be able to access all the type members you’re trying to hide (assuming that part is moved to it’s own submodule). Right now `public` and `open` doesn’t make any sense in such projects, which is a pity.
> 
> 
> Am 29. Oktober 2017 um 15:37:38, Mike Kluev via swift-evolution (swift-evolution at swift.org) schrieb:
> 
>> i am missing some protection level, which can be called "classprivate" or "structprivate" / "enumprivate" (names could be better). here is an example:
>> 
>> --- file Some.swift ---
>> 
>> class Some {
>> private func foo() {
>> bar() // error: inaccessible due to 'private'
>> }
>> }
>> 
>> --- file Some+Bar.swift ---
>> 
>> extension Some {
>> private func bar() {
>> foo() // error: inaccessible due to 'private'
>> }
>> }
>> 
>> 1) i want to have this extension in a different file (to keep file sizes manageable).
>> 
>> 2) i can't use either private or fileprivate due to compilation errors
>> 
>> 3) i do not want to have neither "foo" nor "bar" public
>> 
>> 4) "internal" doesn't help as "foo" and "bar" will be available to my app (which is unwanted).
>> 
>> is there some "classprivate" to help here? if not so far, shall there be one? opinions?
>> 
>> Mike
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution