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 > <[email protected]> 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 > ([email protected]) 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
