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 <[email protected]> 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 <[email protected]> >> wrote: >> >>> On Feb 21, 2017, at 7:38 PM, Robert Widmann <[email protected]> >>> 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 >> > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
