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 < swift-evolution@swift.org> wrote: > > On Mar 29, 2016, at 17:47 , Brent Royal-Gordon <br...@architechies.com> > 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 > 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