[Accepted with Modifications] SE-0339: Module Aliasing for Disambiguation

Evolution Announcements
1

Hello, Swift community.

The review of SE-0339: Module Aliasing for Disambiguation concluded on Monday.

Feedback was strongly positive. There were a few concerns raised during the proposal:

  • Many people expressed their desire for language features like sub-modules which would substantially reduce the need for this kind of retroactive renaming. The Core Team agrees that this remains an important part of the vision for modules in Swift.

  • It was observed that the proposal does not work for pre-compiled modules that cannot be rebuilt to respect the rename. The Core Team sees this as an intractable problem for the full set of situations that this proposal aims to address. The ability to produce ordinary objects and images for C-like binary toolchains is a core strength of Swift, and these toolchains simply are not designed to support the kind of pervasive rewriting or targeted symbol exposure that would be necessary to make a feature like this work on compiled modules. The only reasonable solution for conflicts involving compiled modules is to avoid them proactively by using language features like sub-modules.

  • A community member pointed out that the proposal makes it an error to declare conflicting aliases for a module, and that this can make it impossible to fix conflicts that arise after a rename. For example:

    • Package A provides a module named Utils.
    • Package B renames A's Utils module to GraphUtils.
    • Package C has its own GraphUtils module, and it wishes to rename A's Utils module to MyGraphUtils, but doing so introduces an unresolvable conflict.

    The proposal author has agreed to change the proposal (and its implementation) so that more-dependent renames take precedence. In this example, A's Utils module would be built as MyGraphUtils, aliased to Utils within package A, and aliased to GraphUtils within package B.

Modifications to proposals sometimes require the review to be extended to ensure that there are adequate eyes on the modification. In this case, the Core Team believes that the modification was modest in its effect on the proposal, and since the modification was agreed to fairly early in the review period, we think it's been adequately aired. Accordingly, SE-0339 is accepted with modifications.

I'd like to thank the community for its contributions and for once again demonstrating the power of open review to make things better.

John McCall
Review Manager

16 Likes
2

Is there any way to do this in an Xcode application using package dependencies?

1 Like
3

+1 for this
@JetForMe did you ever figure out if this was possible?

4

I have not