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

Robert Widmann devteam.codafi at gmail.com
Tue Feb 21 20:54:18 CST 2017


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 <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()`?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 



More information about the swift-evolution mailing list