3 ms·

That's correct-- Swift's native String/Array/etc. are part of Swift's native stdlib. NSString/NSArray and friends (along with the bridging code to go between

That's correct-- Swift's native String/Array/etc. are part of Swift's native stdlib. NSString/NSArray and friends (along with the bridging code to go between them and the Swift stdlib types) are part of the open-source Foundation, though. Eventually, that should be present in any reasonably complete Swift runtime environment-- it includes APIs, like networking and date/time handling, that would typically be considered essential but aren't part of Swift's stdlib.

vram22 11y ago
Whats with all the NS prefixes? Stands for NextStep?
- JonathonW 11y ago
  Yes. It's a poor-man's implementation of namespaces, since Objective C doesn't have them and they didn't want to pollute the global namespace with their core classes.
stormbrew 11y ago
The bridging is actually in the swift libraries. Much of it in C++, not in swift, but still. https://github.com/apple/swift/blob/master/stdlib/public/core/BridgeObjectiveC.swift https://github.com/apple/swift/blob/master/stdlib/public/cor... is where the magic starts (and mostly refers to where the actual work is done). AFAIK Foundation does not have any special handling for swift at all. Swift is just taking advantage of the fact that the people working on it can act with authority on the memory layout of Objective-C Foundation objects. Also the OSS Foundation is... not quite the same thing as what apple ships on their platforms.
- JonathonW 11y ago
  That's where Objective C bridging happens. That's irrelevant on Linux or Android, since there's no Obj-C runtime. OSS Foundation (which is composed of pure Swift code, plus the plain C CoreFoundation which is also open) implements bridging between Swift types and Foundation types itself-- see (for example) the Array extension for bridging to NSArray at [1]. That code's what will (again, eventually) ship on Linux and presumably on Android, because it provides compatibility support for Swift libraries originally targeted to Apple platforms and fills out certain core functionality that's not part of Swift's stdlib (networking being a big one). This work is still ongoing and, if one were to try to actually use it right now, you'd run into lots of bits that aren't implemented yet. [1] https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSArray.swift#L12 https://github.com/apple/swift-corelibs-foundation/blob/mast...
  - stormbrew 11y ago
    That is true. I recognize that to some extent I was talking past you, but I really just wanted to clarify where the responsibility lies when there is an objc runtime.

vram22 11y ago

Whats with all the NS prefixes? Stands for NextStep?

JonathonW 11y ago
Yes. It's a poor-man's implementation of namespaces, since Objective C doesn't have them and they didn't want to pollute the global namespace with their core classes.

stormbrew 11y ago

The bridging is actually in the swift libraries. Much of it in C++, not in swift, but still. https://github.com/apple/swift/blob/master/stdlib/public/core/BridgeObjectiveC.swift https://github.com/apple/swift/blob/master/stdlib/public/cor... is where the magic starts (and mostly refers to where the actual work is done). AFAIK Foundation does not have any special handling for swift at all. Swift is just taking advantage of the fact that the people working on it can act with authority on the memory layout of Objective-C Foundation objects. Also the OSS Foundation is... not quite the same thing as what apple ships on their platforms.

JonathonW 11y ago
That's where Objective C bridging happens. That's irrelevant on Linux or Android, since there's no Obj-C runtime. OSS Foundation (which is composed of pure Swift code, plus the plain C CoreFoundation which is also open) implements bridging between Swift types and Foundation types itself-- see (for example) the Array extension for bridging to NSArray at [1]. That code's what will (again, eventually) ship on Linux and presumably on Android, because it provides compatibility support for Swift libraries originally targeted to Apple platforms and fills out certain core functionality that's not part of Swift's stdlib (networking being a big one). This work is still ongoing and, if one were to try to actually use it right now, you'd run into lots of bits that aren't implemented yet. [1] https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSArray.swift#L12 https://github.com/apple/swift-corelibs-foundation/blob/mast...
- stormbrew 11y ago
  That is true. I recognize that to some extent I was talking past you, but I really just wanted to clarify where the responsibility lies when there is an objc runtime.