Foundation without ObjC Interop?

#1

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.

#2

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
#3

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?

#4

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.

#5

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
#6

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?

#7

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.