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