[swift-build-dev] Allowing further module organization

[Max Howell]

> +1 to Daniel's last comment. My biggest issue with SwiftPM usability right now is the lack of two related things:
> 
> (1) Pure Swift submodules

I would like this too, (could be implemented as some sort of module namespacing instead since with Swift modules the final binary can be composed of multiple modules so that part is separate), needs buy in from Swift core.

> (2) Inability to organize source files in any way other than module membership
> I'm working on a library that is more of a suite of related-but-also-separable feature sets. In a hypothetical pure Swift submodule world, I could make each feature a submodule of the main library: MyLibrary.Feature1, MyLibrary.Feature2, etc., and express any dependencies between them (maybe ML.Feature3 depends on ML.Feature2). Without that, the closest thing I can achieve is to make each one its own module, using underscore delimited names like MyLibrary_Feature1, which is unappealing.

Seems like ML is its own package? It’s just you would like a namespace feature. I certainly relate to the ugliness of a naming prefix. Especially with an underscore.

> So, to avoid those issues, I resigned to making the entire library one module, but then I have to merge all of the source files across all features into a single folder. Xcode groups make this manageable in the IDE, but my flattened source control view is much harder to manage.

You can organize code in modules with subfolders currently:

    Sources/MyLibrary/A/a.swift
    Sources/MyLibrary/B/b.swift
    Sources/MyLibrary/c.swift

Will give you one `MyLibrary` module composed of a, b and c.swift.

Or do I misunderstand?

> In my particular use case, I believe pure Swift submodules would be a better answer, but I imagine that there are others who would rather be able to use folders for file organization only within the same module and providing a choice to users to make both possible would increase the complexity of the manifest and the PM implementation.

Long term we need namespaces or submodules I agree.