[SR-10503] Foundation exports CoreFoundation symbols unnecessarily

[compnerd]

Previous ID	SR-10503
Radar	None
Original Reporter	@compnerd
Type	Improvement

Additional Detail from JIRA

Votes	0
Component/s	Foundation
Labels	Improvement, Linux
Assignee	None
Priority	Medium

md5: 2cbc4011d3ce60c83948bf72d0827d91

Issue Description:

CoreFoundation is an implementation detail of Foundation and should not be re-exported from Foundation. This is the case currently on Windows, but not on Linux/macOS. We should determine the correct course here for the long term and make the platforms identical so that we do not run into cases where code can be built on one target but not another.

[compnerd]

CC: @millenomi @parkera @phausler

[compnerd]

To give more context on this, my goal is to achieve source compatibility across Windows and Linux here, not the actual principal of the issue (where I do think that we shouldn't be exporting those symbols).

[millenomi]

As we discussed on the forums, Core Foundation is not a supported part of swift-corelibs-foundation's API. Historically, it is available on Linux, but not by default: as an artifact of the way the build works on that platform, it can be imported with

import CoreFoundation

and used, but we do not make the same API guarantees we make on Darwin for it and we strongly caution against relying on it.

In general, for new platforms such as Windows where we can avoid that exposure being the case, we want to maintain the symbols and the module not available to outside code. We will not break existing Linux code that uses the above without careful consideration, but we have no announcement about this at this time.

Please use Foundation API instead.

[parkera]

We certainly can't change the story about getting CF symbols when importing Foundation on Darwin platforms; that would break the world...

Our intent here was, though, that on other platforms the Swift-friendly Foundation API was the right stuff to export. I thought we originally did want to restrict the export of CF symbols but couldn't for some kind of technical reason.

[belkadan]

Parts of CF are exposed in the ABI of Foundation, no? Either in public functions or as stored properties.

If that's not the case, you could try experimenting with the new @_implementationOnly import. It's still underscored because it hasn't been fully designed or tested yet, but if it seems to be working, Foundation might be a good testing ground for it.

[millenomi]

(Disregard the previous content of this comment.)

We do have some methods that expose CF types in swift-corelibs-foundation, but we do not reexport CF API the way import Foundation does on Darwin — you can call RunLoop.getCFRunLoop(), and it will yield a CFRunLoop, but the CFRunLoop… family of functions will not be available for you to invoke. On Linux, the CoreFoundation module is in the import path and the symbols are not hidden, so import CoreFoundation will get you those functions, but last we talked that's just the status quo in action and not something we are advising people to use.

[belkadan]

That still counts as being public, though, since the compiler needs to know whether CFRunLoop is something that needs to be managed with ARC. :-/ You'd have to separate CF into "CFTypes" and "CFFunctions" if you wanted to hide that stuff, then. (Or break source compatibility.)

[compnerd]

Well, the cool thing is that you can control that by means of attribute((visibility(...))), which means that it should be possible to partition the API space as needed.