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] <mailto:[email protected]>> wrote: > >> On Mar 29, 2016, at 17:47 , Brent Royal-Gordon <[email protected] >> <mailto:[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] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
