> 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()`? >
internal open and public declarations are exported by a module for consumption by clients of the module. internal declarations scope over the entire module and any derived submodules. This way you can consume your own interface without it crossing the module boundary. > -- > Brent Royal-Gordon > Architechies >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
