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]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
