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

Reply via email to