[swift-evolution] [swift-corelibs-dev] Proposal: Swift Open Source Project and Foundation replacements

[Maxthon Chan]

The thing is, I can, in fact, point out a few libraries I would like to use in Swift and as of now you cannot provide it:

GNUstep GUI (AppKit) and UIKit - anything that have GUI in it will need either of those libraries, and GNUstep’s version works perfectly under Linux as well as Windows.
GNUstep GSWeb (WebObjects) and GDL2 (Enterprise Objects Framework) - Web development stack, ain’t this your initial intention of allowing Swift to be run on Linux?
GNUstep SimpleWebKit (lightweight Web browser framework, depend on AppKit)
GNUstep Base for Windows (Foundation, but it works under Windows while yours currently don’t) - better cross platform capability from the get-go.

And a few other libraries that are nice to have:

CocoaAsyncSocket
Objective-C LINQ
CGIKit (a lightweight replacement for WebObjects) - another Web stack

Also by maintaining Objective-C compatibility means you can free yourself from the burden of maintaining any runtime libraries except the Swift standard library itself, as it would allow you to offload Foundation and all other supporting libraries to other, existing, Objective-C-based projects, like GNUstep.

> On Dec 4, 2015, at 21:39, Adrian Kashivskyy <adrian.kashivskyy at me.com> wrote:
> 
>> Removing Objective-C compatibility in Swift (which does not even have a complete set of libraries yet) in this stage would undermine its usability and the completeness of the libraries, and when the project finally matured a bad reputation of “incomplete support” would already be out there, hampering its use.
> 
> Could you point out five Objective-C Linux libraries (apart from GNU Foundation) that you'd like to use in your Swift projects on Linux? I suspect you can't and that's why I strongly disagree. You only need Objective-C on Apple platforms – and that's not going away. 
> 
> Maintaining Objective-C interoperability for non-Apple platforms is a very niche aim and could potentially lead to longer development and evolvement process. That's a reasonable tradeoff.
> 
> Pozdrawiam – Regards,
> Adrian Kashivskyy
> 
>> Wiadomość napisana przez Maxthon Chan <xcvista at me.com <mailto:xcvista at me.com>> w dniu 04.12.2015, o godz. 11:54:
>> 
>> Let’s take a look at C# which Microsoft designed to replace C++ MFC. The compatibility is never removed although C# itself is pretty complete already. During early days (2002) lots of components in C# are stubs calling back to MFC but nevertheless this presented a more or less complete library set to the user and allowed the language to gain traction - so many traction that now people demand it to be ported to multiple platforms.
>> 
>> Removing Objective-C compatibility in Swift (which does not even have a complete set of libraries yet) in this stage would undermine its usability and the completeness of the libraries, and when the project finally matured a bad reputation of “incomplete support” would already be out there, hampering its use.
>> 
>>> On Dec 4, 2015, at 18:33, Alex Blewitt <alex.blewitt at gmail.com <mailto:alex.blewitt at gmail.com>> wrote:
>>> 
>>> A more interesting question would be: is Swift designed to ultimately replace Objective-C? If so, baking in compatibility from the outset of the open source version would probably be going in the wrong direction.
>>> 
>>> Alex
>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151204/2bac4de1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4097 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151204/2bac4de1/attachment-0001.p7s>