On Tue, Feb 21, 2017 at 8:51 PM, Robert Widmann via swift-evolution < [email protected]> wrote:
> > 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 > Huh? Brent wants `bar()` to be visible inside `foo()`, but not `baz()`. How can they both use `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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
