i agree. a criss-platform base library that works in both Xcode and Silve rwoiuld be great to have. i see two potential avenues here that we are thinking about/exploring.
One would be be to have Sugar (or something like Sugar), (re)written in a way that it can either be compiled in Xcode, or ate the very least be compile into a framework that can be used on Xcode — allowing to write code against the Sugar APIs and use that code in both compilers.
The other would be to have Foundation (i.e. the version coming in Swift 3.0) build in Silver (or have an equivalent version of the framework that does), so that instead of Sugar, Foundation APIs would be available cross-platform in Silver (and Oxygene/C#, as well).
How feasible the second portion is depends a lot on what “Swift 3.0 Foundation” will look, and how nasty the code will be on the inside (for comparison: getting Apple’s ow Swift Base Library to compile in Silver and cross-platform is a compete no-go, as there code is a mess of hacks specific to internal stuff in their compiler. Which is fine of course, for such a base library). We;'ll have to see if Foundation will be “clean”, to see whether we can compile it (opposed to duplicate it).
As for Sugar being written in Oxygene — currently it is, yes, as it predates Silver. That said, we’d very much welcome contributions written in Swift. This includes new functionality but also existing functionality rewritten/converted into Swift, and existing functionality rewritten to work in Apple Swift as well.
Jon, you mentioned writing your own library that works with both compilers. Any chance you would be willing to open this up as an open source/community project that we could build one and RO could get involved in with as well, so that everyone could benefit from it, long term (e it as replacement to alternative to Sugar)?
@mh Thanks for elaborating on this. I guess it might be a big challenge to compile the Foundation to Sliver, so maybe having a Foundation-close base library might be the most feasible option, especially in the lights when apple’s Swift Toolchain will be ported to Android. @jnermut made a good point - If Silver can provide a subtle alternative to Apple base libraries, only then it can really compete. But there is still a pretty long way I guess, maybe not even a year until Apple’s port will be usable.
So you might want to check out this - https://github.com/PureSwift/SwiftFoundation
This is a pure Swift Foundation that does not depend on CoreFoundation. It obviously doesn’t compile, apart from Darwin preprocessor directives, silver seems to not eating throws, Swift’s base types like RawRepresentable and many more stuff.
I am quite new to Silver (just discovered you guys last week), but it seems that the lib is not too fat still, so there wont be too much overhead porting it to Silver I hope. I will take some time to get around Silver and Sugar cuisine and try to elaborate on that. What do you think?
We’ll look at getting that too compile, at https://github.com/remobjects/SwiftFoundation/tree/develop. Already added RawRepresentable and more missing stuff to our SwiftBaseLibrary, and workarounds for “Darwin.C”, as well as an Elements project (just OS X for now). Several compiler fixes/changes will be needed tog et this working, and we’ll look at letting the help set priorities…
Feedback & contributions will be appreciated, obviously, once we get past the most obvious issues that need changes from our end.
Any chance you would be willing to open this up as an open source/community project
Unfortunately not as it’s current form, as it’s part of a big commercial project, but I would definitely contribute to an open source effort.
I think replicating Foundation is the way to go. It’s a big project though. It’s a very ugly API, but unfortunately it’s the current standard for Swift development. I’m including libdispatch in that category too, which is used in most non-trivial swift libraries/frameworks.
I had forgotten about the PureSwift effort. I think it was started assuming that Swift on Linux wouldn’t actually include Foundation, but in the end Apple open sourced an incomplete implementation for Linux. But maybe a fork of that PureSwift lib is a good place to start on a Silver Foundation library.
I’m not sure how compatible it is with Apple Foundation though? I think they are trying to cut out some of the cruft, which might mean that you couldnt actually use libs designed for Apple Foundation.
As I understand it, Foundation on Linux is a completely separate code base to the original iOS/OSX Foundation, which isn’t open source. And just about all of the Linux impl calls straight out to C APIs - either POSIX or GLIBC. Which makes both pretty much useless for Silver besides guidance (I would have thought).
Also, as I understand it, there won’t be any major API changes in Foundation in swift 3.0: it’s listed out of scope here:
Not sure if they are going forward with removing the NS* prefixes though.
@mh thank you for the effort and consideration. I will watch closely for the update on it, looking forward to it. I think I do not have access to the silver’s private betas.
Now that Swift 5 has finally ushered in ABI stability, perhaps this thread deserves to be resurrected…
Other than utilizing precompiled binary Swift libraries, support for pulling in dependencies utilizing Swift Package Manager (SPM) package files would be most gratifying to see on the roadmap.
this needs Module Stability, which is coming in 5.1 (but alas without ANY kind of formal spec or documentation ), but we are slowly working on it for Island/Darwin and ToffeeV2, yes.
Work in progress, but since there is absolutely zero documentation on the actual ABI, and the ABI is also a total shitshow, it’s very slow going. Another month or two, I’d expect, at least.
Also, expect the “stable” ABI to break for he next release, because the way this is designed, there’s close to no way this can actually be stable long term. Apple is aiming a bazooka-sized weapon at the foot fo their developer ecosystem with what they are doing here, and it’s gonna come back to blow up in their faces, if not soon, then edition the next five or so years.
), but we are slowly working on it for Island/Darwin and ToffeeV2, yes.