1

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

1 Like
2

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.

···

On Oct 29, 2017, at 7:37 AM, Mike Kluev via swift-evolution <swift-evolution@swift.org> wrote:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

Internal is the best choice available at the moment but I wouldn’t call it the “right” choice. Languages with the concept of classes often have a “protected” scope with means “visible within this class and subclasses”. In Swift that could mean “visible within this class, subclasses, and extensions” which would also make it useful for structs/enums, etc. I’ve also wanted such an access level on numerous occasions.

···

On Oct 29, 2017, at 12:04 PM, Adam Kemp via swift-evolution <swift-evolution@swift.org> 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.

On Oct 29, 2017, at 7:37 AM, Mike Kluev via swift-evolution <swift-evolution@swift.org> wrote:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

1 Like
4

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution