Once again, internal is your keyword. An extension allows you to “open and expand” the module boundary here, which is exactly what you want here - to extend this module across file boundaries without showing your cards to an external consumer of your framework.
> On Feb 21, 2017, at 10:26 PM, Xiaodi Wu <[email protected]> wrote: > > On Tue, Feb 21, 2017 at 9:08 PM, Robert Widmann via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > Sorry, been replying to multiple sub-threads today. > > > For bar(), because you wish to be able to > > 1) Not export it across the outermost module boundary > 2) But still use it internally > > Internal access is required. Any higher and you would export (violating 1), > any lower and you wouldn’t be able to internally import (violating 2). > > For baz(), because you wish to be able to > > 1) Not export it across the outermost module boundary, > 2) Or even your own internal submodule boundary > > 3) But still use it within the same submodule, across different file > boundaries: this is the feature that many people have stated they want to > emerge out of a submodule design. > > Private or fileprivate suffices depending on the scoping you wish for it to > have within the file/interface it’s a part of relative to the other APIs in > the submodule. > > > On Feb 21, 2017, at 10:04 PM, Brent Royal-Gordon <[email protected] > > <mailto:[email protected]>> wrote: > > > > I specified two different behaviors for `bar()` and `baz()`. I see now that > > you describe `internal` as having the behavior I want for `bar()`. Is there > > a way I can get the behavior I want for `baz()`? > > > > -- > > Brent Royal-Gordon > > Sent from my iPhone > > > > On Feb 21, 2017, at 6:51 PM, Robert Widmann <[email protected] > > <mailto:[email protected]>> wrote: > > > >>> 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 > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
