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

[Robert Widmann]

Whoops, move bar() out of the utility and you get the actual answer here, because you want to be able to see this in foo()!

> On Feb 21, 2017, at 10:54 PM, Robert Widmann <devteam.codafi at gmail.com> wrote:
> 
> This case is unserved because it is anti-modular and a nightmare to maintain.  The actual way to structure this is to factor bar() and baz() into their own utility submodule, or even deeper if necessary, that has as a parent the primary module that wishes to consume them both but not re-export them out to the parent.  For example,
> 
> 
> 	// foo.swift
> 	import MyMod.Submodule
> 	func foo() {
> 		bar()
> 	}
> 
> 	// bar.swift
> 
>        // Make my utilities visible in Foo.Submodule, but invisible to the parent.
>        import Foo.Submodule.UtilitySubmodule
> 
> 	module Submodule {
> 		module UtilitySubmodule  {
>                   internal func bar() {
> 			baz()
> 		  }
>               }
> 	}
> 
> 	// baz.swift
> 	extension Submodule.UtilitySubmodule {		
> 		internal func baz() {
> 			…
> 		}
> 	}
> 
> The thought is that it should be as cheap to create submodules to organize interfaces under as it is to create new directories to organize code under.
> 
> Though, this example is a little odd given that you’re defining and importing the same utility submodule.  Really, what you would want to do is declare the utility in its own file/files outside of bar.swift to really take full advantage of the separation afforded here, then consume it internally with the import as written here.
> 
>> On Feb 21, 2017, at 10:47 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> 
>>> On Feb 21, 2017, at 7:38 PM, Robert Widmann <devteam.codafi at gmail.com> wrote:
>>> 
>>> Correct.  Because, in dividing the submodule across an extension, you have placed what should be a private API into a differently-scoped location.
>> 
>> Okay. So is your submodule design not intended to address the "I want to encapsulate implementation details so they're only visible to several units of code in different files, but not the entire module" use case? Because if there's no way to scope a symbol to "everything inside this submodule, but nothing outside this submodule", I think it leaves that use case unserved.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>