[swift-evolution] classprivate protection level?

Adrian Zubarev adrian.zubarev at devandartist.com
Sun Oct 29 14:35:59 CDT 2017

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?


swift-evolution mailing list
swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171029/aba0f8fb/attachment.html>

More information about the swift-evolution mailing list