How about public, private, private(#file), and private(#module)? At a later date, if needed, private(S1, S3, ...) could be added. This would be a minimal change and not stop an extension in the future if requested.
On Thursday, 31 March 2016, James Campbell via swift-evolution < [email protected]> wrote: > What about local for a file only or scope definition ? > > Sent from Supmenow.com <http://supmenow.com> > > > > > On Wed, Mar 30, 2016 at 12:39 PM -0700, "Jordan Rose via swift-evolution" > <[email protected] > <javascript:_e(%7B%7D,'cvml','[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] >> <javascript:_e(%7B%7D,'cvml','narrativium%[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] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >>> >>> On Mar 29, 2016, at 17:47 , Brent Royal-Gordon <[email protected] >>> <javascript:_e(%7B%7D,'cvml','[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] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >> >> -- -- Howard.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
