Re: Should we split the project into two branches?

[Max Chan]

This kind of layering is the easiest and the most robust way of implementing all those toll-free bridging. You can see where NSObject lives as that is required or toll free bridging to work. Also through my probing a lot of Foundation classes actually lives in CoreFoundation binary.

If we build our Swift Standard Library on our current library layering, it means even for small Swift-only projects the full Foundation library has to be loaded into the memory with its vtable, which can be quite a memory hog. Apple’s layering likely is based on the fact that the same layering is also used on iOS, which is memory constrained. Also Swift code calling Swift code doesn’t use objc_msgSend, so by not loading Foundation unless necessary we don’t have to build out the Objective-C vtable for such Swift-only programs unless they use interoperability.

Here is a fuller view of Apple’s layering:

Mac OS X 10.6.8:

* libc

  * libobjc

    * CoreFoundation (NSObject likely here)

      * Foundation

macOS 12.2:

* libc

  * libobjc2 (NSObject here)

    * CoreFoundation (plus a ton of Foundation classes, even though their header files are not here)

      * Foundation (actually very barren class wise)

      * Swift Standard Library (also depends on libswift, equally barren code-wise as Foundation)

    * libswift (Swift runtime)

Swift 5.5 release for Linux:

* libc

  * libswift (contains a minimal libobjc2)

    * CoreFoundation (Swift-only incomplete reimplementation)

      * Swift Standard Library

      * Foundation (Swift-only incomplete reimplementation)

On Feb 15, 2022, at 3:01 AM, H. Nikolaus Schaller <hns@computer.org> wrote:

Am 15.02.2022 um 08:44 schrieb Max Chan <xcvista@me.com>:

This is just whack…

What I mean by saying we need refactoring, is that our library structure is twisted and may not bode well for future Swift integration. Here is ours:

* libc
* libobjc2
  * Foundation (NSObject here)
    * CoreFoundation

And here is Apple’s:

* libc
* libobjc2 (NSObject here)
  * CoreFoundation
    * Foundation
    * Swift Standard Library

Now do you see my point? (Don’t worry with Swift Standard Library to Foundation toll-free bridging, all of those goes through CoreFoundation.)

We had a long discussion about that when CoreFoundation API came. At that time there was no Swift.
So it felt the easiest thing to add the new API by wrapping existing Foundation classes...

But what I wonder is the following:
If Foundation and CoreFoundation have well defined and stable interfaces why does implementation matter at all?
Is there even a requirement that they are layered on each other?
Can't they be completely separate implementations of some API used by compilers and developers?

signature.asc
Description: Message signed with OpenPGP