[swift-evolution] SE-0025: Scoped Access Level, next steps

[Ross O'Brien]

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 at swift.org> wrote:

>
> On Mar 29, 2016, at 17:47 , Brent Royal-Gordon <brent at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160330/08de35d4/attachment.html>