> 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
