What is implied by the definition of `internal` in the proposal (which should, as this thread has shown, be stated explicitly) is that by “export” we mean “export to clients” across the outermost module-boundary. Any API that is not public is, by definition, not able to cross this outermost boundary. Internal API is allowed to cross internal boundaries if it is imported internally. Private and fileprivate API may not, as the name implies, cross file boundaries and so cannot be allowed to cross either boundary.
> On Feb 21, 2017, at 9:49 PM, Brent Royal-Gordon <[email protected]> > wrote: > >> On Feb 21, 2017, at 6:43 PM, Robert Widmann <[email protected]> wrote: >> >> That is not what this proposal requires. A public API is ripe for >> re(export), but if the parent wishes to communicate with its children >> without exporting across the module boundary, see the definition of >> `internal`. > > I'm not sure whether I'm misunderstanding or we're talking past each other. > > Let me state this really simply. You have some code in a top-level module, > `MyMod`: > > import MyMod.Submodule > > func foo() { > bar() > } > > And you have some other code in a submodule: > > module Submodule { > ??? func bar() { > baz() > } > } > > And then—perhaps in a separate file—you have some other code in an extension > of the submodule: > > extension Submodule { > ??? func baz() { > … > } > } > > What access modifiers do I put on `bar()` and `baz()` so that `MyMod` can > access `bar()` but not `baz()`, and code outside `MyMod` can access neither > `bar()` nor `baz()`? > > -- > Brent Royal-Gordon > Architechies > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
