Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing me directly, please keep the proposal link at the top of the message and put "SE-0339" somewhere in the subject line.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
A related concern that the proposal doesn't seem to flag is that this doesn't affect evolution. It remains the case that adding new modules can introduce clashes where they did not exist before, and cause build breakages. Module aliases need to be applied at the scope where they cause a conflict, and that is never going to be within the package that added the new module. So projects like NIO continue to need to namespace any new targets they add.
If there are multiple aliases specified for a module, it will throw an error during dependency resolution and fail to build. If a module has been aliased lower down, there shouldn't be a need to alias it again at the top level.
If a library package adds a new module within the package, it will need to use a non-conflicting name. Even if a package uses a namespace for its targets, a conflict can still occur at the top-level and module aliases can be applied to resolve the conflict.
With a standard dependency declaration, “MyPackage” would have two clashing “SoundUtils” and at least two clashing “Utils” modules. What should it specify in moduleAliases for one or both of its dependencies in order to resolve the problem?
Perhaps MyPackage ought to be able to set moduleAliases: [Sound: GamingSound, SoundUtils: GamingSoundUtils, Utils: GamingUtils] on its Gaming dependency, and then those would be substituted into the module aliases of Gaming's own dependencies.
That was my intuition as a user too. But the proposal does not describe the intent in this scenario, and the PR appears to blindly collect a flat dictionary from the graph, basically with merge‐by‐overwrite. Given that the resolver still suffers from a non‐deterministic order of traversal in some parts of the code, I am not confident that it is even possible to predict the resulting module name with the pull request’s implementation. It does not need to be actually fixed before the review is accepted, but it would be good to have the intent clarified first.
Also, just a minor criticism of the proposal text: currently the example package manifests included in the text are written in a weird mixture of JSON and Swift or something like that. It would probably be better to write them in normal Swift code, just how they would be written in a real package (also the *s around the moduleAliases parameters surprised me a bit when I first read them, I think it's better to leave them out).