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
Is there a reason why straightforward PRs get ignored for weeks/months?
The swift-crypto PR is still open (although the person should just be blocked and the PR closed, so someone who doesn't do license laundering can create a new PR)
Then these are also already 2 weeks old:
1 Like
Yesterday I went through my package-in-progress and Essentials-ized as many imports as possible. Of the source files that actually needed Foundation, in a few cases it was due to Unicode support, which I can probably do without, but more often due to the use of FileManager or Input/OutputStream.
It seems sad that I can’t use standard filesystem APIs without dragging in all of ICU too.
Is there any alternative? I know about FileDescriptor (sp?) but that would require writing a higher-level streaming API around it. It might also expose platform-specific behaviors. And as for a DIY FileManager, I know from experience that building a robust cross-platform API for manipulating the filesystem is nontrivial.
3 Likes
Can you try NIOFileSystem?
3 Likes