What does importing Foundation without ObjC interoperability enabled mean? How is this scenario expected to work? I ask because stmt/errors_nonobjc.swift superficially "tests" this scenario.
I assume you are talking about the !DEPLOYMENT_RUNTIME_OBJC builds for Darwin.
Importing Foundation without Objective-C interoperability means that you are using swift-corelibs-foundation for the Foundation implementation on Darwin rather than the traditional Objective-C based Foundation implementation. This allows us to test the implementation of the Swift implementation of Foundation on Darwin.
CC: @millenomi
1 Like
So the test which prompted the question just mocks up a stub “Foundation” with pure Swift code. Does swift-corelibs-foundation depend on “bridging” like Foundation does?
There is a concept of bridging in [Swift] Foundation. NSSwiftRuntime sets up some of that bridging some of the Foundation types to the CoreFoundation types. As an example, CFString is bridged to NSString which is bridged to String.
How would one specify this option (or lack there of) when building a SPM package?
I only see a flag to define an option.
-D <value> Marks a conditional compilation flag as true
So what motivated this discussion is that I experimented with having ASTContext::getBridgedToObjC always return Type() if ObjC interoperability is disabled. This broke one test: stmt/errors_nonobjc.swift
If swift-corelibs-foundation requires bridging but not the ObjC runtime, then getBridgedToObjC probably ought to be renamed, right?
Ah, yes, that has grown disjoint from the original name and no longer fully represents what it is meant to be. Renaming would probably be a good idea so that someone else doesn't trip over the same mine.