That should still be fine if A in the example above doesn’t itself re-export Foundation, right? Or does the exception apply through the whole tree?
In isolation, I think that case would be fine.
In practice, for a project that has many more imports, it might not be as straightforward. Clang modules are notoriously leaky as well, at least in Apple's SDKs, which all use export * to avoid breaking clients when they migrate to modules if they rely on C's "importing a header means you can see everything it imports, transitively" textual inclusion behavior. So importing some other Clang module in that file, if it depends on Foundation, might cause the same issue to reemerge.
Of course, this may not be the case on non-Apple platforms where Foundation has a pure Swift implementation (ignoring CoreFoundation, of course), and that seems to be the focus of this discussion. I would hope that Apple platforms would also figure out how to represent FoundationEssentials/Internationalization as well so that we can truly write cross-platform packages without conditional compilation, but I realize there are decades worth of ABI and source compatibility concerns at play there, which are also entirely out of scope for the Swift open-source project.
3 Likes
Is anyone actually working on getting the changes merged? I've seen no activity in the repos that are blocking my projects from removing Foundation dependency:
As for InternalImportsByDefault, I think it should've been something that's defined in Package.swift (and through swiftc parameters when using cmake/etc.), so there is a single source of truth for which dependencies are allowed to be used in public APIs.
I am slowly working through some. Did PRs for protobuf: Move runtime to `FoundationEssentials` by madsodgaard · Pull Request #1993 · apple/swift-protobuf · GitHub and looking at openapi-runtime.
The changes should be quite simple if the package does not use anything from Foundation. So I am sure the maintainers would appreciate a PR 
1 Like
I mean the ESG update was literarily yesterday... Yes, SSWG projects will move to adopt this pattern.
3 Likes
It might make sense to add a CI step to validate that the produced products don't "accidentally" link Foundation. I think we did something like this in the AWS Lambda runtime. CC @sebsto
4 Likes
Indeed, I wrote a script that runs in the CI to check the absence of foundation-related libraries. The scripts builds a Lambda function and checks that the binary is not linked with libFoundation.so, libFoundationInternationalization.so, or lib_FoundationICU.so
The scrip is here
Happy to read your feedback
8 Likes