What about local for a file only or scope definition ? Sent from Supmenow.com
On Wed, Mar 30, 2016 at 12:39 PM -0700, "Jordan Rose via swift-evolution" <[email protected]> wrote: Ah, sorry! Those are all clear to me; it's the possibility of writing some other module name there that would have the wrong implications. Jordan On Mar 30, 2016, at 12:38 , Ross O'Brien <[email protected]> wrote: Damn, and I thought it was clear all this time that 'private(module)', or 'private(#module)', or 'moduleprivate', meant that the symbol is visible only inside the module. It's always been a suggested replacement specifier for 'internal'. On Wed, Mar 30, 2016 at 6:33 PM, Jordan Rose via swift-evolution <[email protected]> wrote: On Mar 29, 2016, at 17:47 , Brent Royal-Gordon <[email protected]> wrote: If Scala style access modifiers were adopted for Swift then a private(file) modifier would also be necessary to give the current private functionality. I could imagine having these options: public // visible to all everyone private(scope-name, scope-name, …) // visible to specified scopes (plus current scope) private // visible only to current scope scope-name could perhaps be: * A type name (or Self, which would mimic C++-style private, or perhaps even C++-style protected depending on how we treat inheritance) * A module name (or #module for the current module) * A file name string (or #file for the current file) And then the default would simply be `private(#module)`. Alternatively, the parameterized level could be given a different name, like `internal` or `shared`. If that were the case, then `#module` might simply be the default. I've actually thought about this before (well, at least at the module level) and ultimately decided it was a bad idea for it to be part of the access control system. Why? Because there's nothing "private" about sharing with another module, even if it's just one other module. - You don't get any secrecy because you have to publish all symbols and metadata as public.- You can't optimize based on knowledge of how the declaration is used.- Exposing something to another module can be viral, just like making something 'public' would be viral: all of a type's protocol conformances are exposed, a class's superclass must be exposed, all the types in a function signature have to be exposed (or already public). All of this means that this behaves more like "public" than like "private"; it's "public, but not the entire public". The restriction on use sites is an artificial one. Now, it is a very useful feature! Apple, of course, does this all the time with its "SPI". But I think the right form of the feature is to be able to tag a bunch of public declarations as "SPI" or "limited" or "limited to group 'X'" or possibly even "limited to module 'X'", and then have a tool to strip them out of the swiftmodule file when you're ready to ship this module to people. That way you're enforcing your limitations as much as possible, while still using the same binaries for both internal and external clients. (Remember that the swiftmodule file serves essentially the same purpose as header files in C.) At the file level, there's nothing inherently wrong with this idea, but I don't think there's enough gain to writing file strings directly in source files. Pointing to a future "comprehensive submodules model" would be disingenuous because that's a huge feature with a lot of subtlety, but I think "just make this accessible to one other file" is additional complexity for not much gain. It's also subject to slippery-slope: once one file is added, I don't think anyone would think too hard about adding a second file, and then… Jordan _______________________________________________ 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
