Why are things from one modules found in another module?

Using Swift
, ,
1

I discovered the following:

// import nothing
exit(1); //error: not found

import Foundation;
Foundation.exit(1);

These are normal, but then:

import Metal;
Metal.exit(1); // works!?

import HealthKit;
HealthKit.exit(1); // What?

Other things also apply. For example finding CFArray in HealthKit.

I can’t understand why. Did ALL of those modules did a @_exported import?

2 Likes
2

We have some module leaks, this may be some of them. :man_shrugging:

2 Likes
3

Yes, these seem to be examples of Clang re-exports @tshortli mentions in the linked post:

Clang re-exports

As mentioned in the proposal, it is conventional for Clang modules to use export *, which has the effect of re-exporting every module that is imported by the Clang module.

Both HealthKit and Metal are (primarily) Objective-C frameworks, and they both have export * in their respective modulemaps.

2 Likes
4

If folks are interested in the history behind this, this goes back to how Clang implemented modules: Modules — Clang 23.0.0git documentation

The wildcard export syntax export * re-exports all of the modules that were imported in the actual header file. Because #include directives are automatically mapped to module imports, export * provides the same transitive-inclusion behavior provided by the C preprocessor, e.g., importing a given module implicitly imports all of the modules on which it depends. Therefore, liberal use of export * provides excellent backward compatibility for programs that rely on transitive inclusion (i.e., all of them).

Basically, if you had code that was doing #import <UIKit/UIKit.h>, in a textual inclusion world, your translation unit also has access to everything that UIKit.h imports, recursively. In order to make migration to modules (i.e., @import UIKit;) feasible, they had to have a way to replicate that re-export functionality, otherwise developers would be playing whack-a-mole to import whatever transitive dependencies they were also using.

I wish Swift had broken from this and required explicit imports, but it is what it is. What probably never should have been allowed, though, is using explicit qualification to reference a declaration in a different module than it's declared in. We should definitely forbid Metal.exit(0) and provide a fix-it that points to the actual module name...

...but that gets gnarly as well. Do you know what module exit() is actually defined in? It's not Foundation. Is it Darwin? Not exactly. It's _DarwinFoundation3._stdlib (at least today it is), which nobody should ever touch explicitly. The C standard library modules are full of these little implementation details, and they've actually shifted around a lot over the past couple major versions of Xcode. So we'd probably want the canonical public entry point to be Darwin.exit(0), but that would require a way to differentiate "this module is re-exported because we want to craft a particular API surface" from "this module re-exported because of historical reasons and nobody should rely on that".

12 Likes
5

Yeah, module re-exports are a double edged sword. They are an important tool for source compatibility when it becomes necessary to break up an existing module into smaller modules (to resolve a dependency cycle, for example). We can't remove that tool from the language, and it's necessary to preserve source compatibility with module qualified references in the specific case that declarations are shuffled between modules. On the other hand, though, the fact that all Clang modules in Apple's SDKs blanket re-export every other module they import leads to surprising behavior from the perspective of Swift clients since blanket re-exports are not the default expectation in Swift.

I've actually considered making a proposal to address this as a source break in some upcoming language mode but I have yet to nail down the details of how we want the alternative to work. Anything we do to change this is going to have widespread impact to the ecosystem.

4 Likes