I wonder if perhaps it would be clearer if public was used for indicating something was published, even if it is published to a restricted set:
public(#all) - expose outside the framework, shortened to public public(#module) - exposed module-wide, default if omitted public(#file) - expose to other code within the file private - not exposed outside lexical scope named contexts such as a particular type or other module would be possible in the future via non-# names, and multiple contexts could be possible in the future via comma-separated values -DW > On Mar 30, 2016, at 7:24 PM, Matthew Judge via swift-evolution > <[email protected]> wrote: > > Some other module name would seem to suggest "public(scope-name)" > > I agree "private(scope-name)" should only be used to disambiguate between the > concentric scope circles (if I declare something in the main class it is > visible in the main class declaration scope, the file scope, and the module > scope... And I can declare something private to any of those scopes). > > On Mar 30, 2016, at 15:39, Jordan Rose via swift-evolution > <[email protected] <mailto:[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] >>> <mailto:[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] <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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
