[wsc981]

I would expect this just to be basic Swift support including -perhaps- the Foundation library (String, Array and other "low level" functionality). I don't think this Swift port has currently any easy way to create apps with a graphical user interface using some sort of Java bridge. So compared to Xamarin, using Swift for Android apps would be pretty limited.

But please correct me if I'm wrong.

[stormbrew]

Swift String, Array, etc. are not part of Foundation, they are part of the swift runtime library. They have mechanisms for converting to and from NSArray/NSString representations, though (and because of that, their internal structure is quite similar). But that mechanism is disabled in Linux (and obviously I assume Android).

[JonathonW]

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.

[stormbrew]

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/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]

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

[stormbrew]

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]

Whats with all the NS prefixes? Stands for NextStep?

[JonathonW]

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.