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
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.