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

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

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.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.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

More information about the swift-evolution mailing list