[swift-build-dev] Proposal: SwiftPM Target Access Control

[Ankit Agarwal]

> 1. One major reason for wanting control over which targets are exported
> are so packages can control which parts of their API is supported for
> external use. This is very important to large projects undergoing active
> development while also trying to support a well-defined, semantically
> versioned API.
>
> 2. In keeping with #1, and the design of the Swift language, I think the
> right default is for a module to be private/unexported. This is basically
> for the same reasons as `internal` is the default access control modifier
> in Swift. This also relates to the discussion below.
>

I agree keeping things unexported/internal will make sure a certain module
is not being used as a dependency when it shouldn't. I also think the
default behaviour of a dependency package being exposed to every target
should be discontinued with this proposal and each target which wants to
use a certain external dependency should require explicit declaration. This
will make the manifest file clearer as to which target exactly depends on
what.
However it might break all currently packages (which is probably okay) but
it might also get confusing for beginners that why their package is not
compiling after declaring the external package. We can probably provide a
useful warning when an external package is declared but there is no
reference of it in any of the targets.


> 3. If we are going to add this via a new Target attribute, I suggest we do
> so using a `flags` parameter and accompanying enumeration. This will be
> equally readable, I think, but more extensible over time.
>
4. Technically, this proposal is defining two new few features, the
> public/private exported/imported part and the ability for packages to
> depend on specific targets. They are related problems, but the proposals
> (and implementation) are otherwise somewhat orthogonal. I'm fine combining
> them into one proposal, but if it appears that one part is going to require
> much more design or discussion than the other (or that the combined
> discussion is too large) we might consider breaking them up.
>
>
I agree.


> There is a larger thing we need to consider with regard to the
> public/private part of the proposal, and that is its relation to
> hypothetical future support for package-level namespaces, whereby I mean
> Swift language support for a new level of namespace (and accompanying
> access control support in some form) for an entire Package. There are
> several reasons I think that we will ultimately need such a thing, the most
> major of which is the module-name collision problem (two packages that want
> to use a shared common name for a module) that cannot be resolved by
> SwiftPM without language support. Since such a feature is purely
> hypothetical at this point, I don't think we need to block forward progress
> in SwiftPM on it, but I do think we should discuss the consequences.
>
> Some examples of how these things might be related:
>
> 1. The choice of `public/private` is probably wrong when viewed as a
> language feature, since they already having existing meanings and
> `internal` would be a more accurate name within the context of an
> individual Package. I think we should include some discussion of the best
> names if we reuse modifier names, or if there is a good argument for
> finding alternate names ("exported/unexported"?).
>

if things are going to be private/internal/unexported by default, I think
we only need to define the public/exported name. Exported seems like the
correct name for this behaviour and is well known however I think public is
also equally clear (and simple) here.


> 2. Suppose Swift added support for a `package` namespace and access
> control modifier. This might make it somewhat awkward if we had tied
> expectations of what targets in an external dependency were built to a
> *manifest*-level construct.
>

If such a feature is added to swift it would probably require to rethink
the manifest file but I agree we should try to minimize the damage if
possible.


>
> 3. We should call out that public/private in this sense ultimately won't
> have any enforcement by the compiler. If a public target exposes a type
> declared in a private module implicitly (say via a return value), there
> won't be any error, even though it breaks the encapsulation this feature
> would partially be intended to provide. Similarly, nothing will prevent a
> target from importing a private module from an external dependency if was
> already a transitive dependency of some other public target.
>

In the current draft proposal I mentioned private target's dependency can
only be another private target for the same reason but I think the approach
of having dependencies providing one (or more) well maintained exported
target makes more sense. True as of now we cannot enforce this and modules
can and will leak out. Maybe we can implement some form of enforcer or
checker using SourceKit in future.

-- 
Ankit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160711/a2a89548/attachment.html>