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

Robert Widmann devteam.codafi at gmail.com
Tue Feb 21 20:51:22 CST 2017


> 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


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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170221/6551e198/attachment-0001.html>


More information about the swift-evolution mailing list