[swift-build-dev] [Pitch] Deeper Xcode Integration for SwiftPM

Adrian Zubarev adrian.zubarev at devandartist.com
Wed May 18 14:37:49 CDT 2016

I’d like to discuss an idea that will make development in Xcode easier. I assume that SwiftPM will see its Xcode integration when the final version will be released.

Problem I’ll try to describe is mostly about namespaces. Right now some people abuses enums, struct or classes to create a namespace for a specific need.

class Reference {
    class String { … }
    class Character {
        enum Error { … }

    private init() {}

This will create a pseudo namespace for the nested types:

* Reference.String
* Reference.Character
* Reference.Character.Error

One could argue of using modules instead of abusing a class here, which is a great argument.

The problem that comes to my mind here is that we will have to create subprojects inside our main project file and using the references to them just to achieve that shiny namespace.
One could also use SwiftPM, which is awesome, but there is a need to re-build the module if any changes have been done. As soon as we’ll create some complex dependencies between different modules this will get messy.

Before posting here I asked Joe Groff if there is any mailing list I can use to discuss my idea. He told me this might be a good place, because I was referring to the package manager. Then I’ve done my research to not create any redundant thread, but I only found one topic about the integration of SwiftPM in Xcode: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

So here are my thoughts about a deeper integration of SwiftPM here:

- What if Xcode will introduce two new types of groups (the folder color could be orange like Swift for example, or even contain the bird icon).
- These groups are analogous to already existing group types except they’ll represent Swift modules / packages
- Basically we’ll have a single project file with multiple modules, where these modules should only exist inside that project (this is my own need right now)
- Such a package / module group will have a configurable utilities, where one could configure the modules
- This will reduce the re-building process, allow us to keep everything (not only .a or we’ll be able to hide .a files and just keep the sourcefiles inside such groups) inside a single project, gain the shiny namespaces like above, and make the file management way easier 
- This also should allow us create cross-dependencies if there is a good need for that in our project

+ MainProject
+—Reference (module)
+—+— Magic (module)
      +— SomeSubMagic (module)

We could easily create cross dependencies between modules here by just using the modules names and the types they provide.

// SomeSubMagic is a sub module of Magic
class SomeSubMagic {
    var magic: Magic // referring to its parent module
What do you think about this?

Adrian Zubarev
Sent with Airmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160518/1a59a3c6/attachment.html>

More information about the swift-build-dev mailing list