[swift-evolution] [Proposal][Discussion] Modular Swift

[Xiaodi Wu]

On Tue, Feb 21, 2017 at 8:51 PM, Robert Widmann via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Feb 21, 2017, at 9:49 PM, Brent Royal-Gordon <brent at architechies.com>
> wrote:
>
> On Feb 21, 2017, at 6:43 PM, Robert Widmann <devteam.codafi at gmail.com>
> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170221/38e03aae/attachment.html>