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

[Maxthon Chan]

Swift without Objective-C support will miss out a few important pieces that is 
crucial to the success of Objective-C outside OS X:

1) AppKit and UIKit. Both GNUstep and Cocotron have their version of AppKit and 
GNUstep even have a version of UIKit. Missing this means there is no way 
writing portable Swift app that have any form of GUI.
2) WebObjects. I know that Apple deprecated WebObjects for Objective-C long 
ago, but its clone in GNUstep is still used and maintained. Missing out this 
means that you cannot easily write Web applications using Swift on Linux 
without going back to CGI or FastCGI - kind of defeats its purpose isn’t it?
3) Code compatibility. One of the best features of both Cocotron and GNUstep is 
that it allows OS X app to be ported to other platforms without changing its 
code. This Swift apparently won’t do this.

Max

> On Dec 4, 2015, at 06:13, Chris Lattner <address@hidden> wrote:
> 
> 
>> On Dec 3, 2015, at 12:01 PM, Maxthon Chan <address@hidden> wrote:
>> 
>> Dear Swift developers:
>> 
>> Maybe you have never heard of it, but there have been several ongoing 
>> efforts, like GNUstep and Cocotron, at maintaining an open source Foundation 
>> reimplementation for alternative operating systems like Linux. It seemed to 
>> me that the current release of Swift did not put such efforts into 
>> consideration and brutally broke compatibility between Swift and Objective-C 
>> on Linux. I understand the fact that Apple is unwilling to release source 
>> code of Foundation, and this is usually where those alternative 
>> implementations comes into play.
> 
> Hi Maxthon,
> 
> Thanks for your interest, we’re definitely aware of GNUstep and Cocotron.
> 
> As others have surmised, the goal for the Swift Foundation project is to 
> provide a pure-swift implementation (which reuses widely-available C 
> libraries) of important Foundation APIs that do *not* depend on the 
> Objective-C runtime.  Reusing GNUstep, Cocotron, or even Apple’s existing 
> Foundation implementation didn’t allow us to achieve those goals, so we 
> didn’t go with those approaches.
> 
> We’re aware that this means that it will take longer for the Swift Foundation 
> to be fully operational and useful, but that is a tradeoff we’re willing to 
> make.  You are of course welcome to make Swift work with GNUstep or Cocotron 
> if you’re interested in doing that, but that seems outside the charter of the 
> work on Swift Foundation.
> 
> -Chris
> 
> 
>> 
>> Some of such projects, like GNUstep, are mature enough to allow existing 
>> AppKit applications written in Objective-C, like TextEdit and Chess, to be 
>> ported from OS X to Linux and Windows without changing too much, if any, 
>> code, taking all modern Objective-C features like ARC and object 
>> subscripting with stride, with a compatible version of LLVM compiler. 
>> Meanwhile, with the current version of Swift, even if the Swift code is 
>> written with calls to Objective-C runtime assuming the case on OS X, it is 
>> broken under Linux even with libobjc linked in.
>> 
>> I am here suggesting keeping the Objective-C bridge intact at least when 
>> built with a compatible version of libobjc (and GNUstep project have one 
>> already.) This will allow users of such alternative Foundation 
>> reimplementations to use their favourite Foundation distribution in place of 
>> the version provided by the Swift project, retaining the code compatibility 
>> already established between OS X and Linux by those Swift reimplementations.
>> 
>> In such an environment the alternative Foundation implementation will 
>> provide their own version of CoreFoundation and Foundation, implemented 
>> using C and Objective-C, as well as a libobjc that supports ARC. The Swift 
>> environment would be built without its own CoreFoundation and Foundation, 
>> but linking against the provided version instead, bridging calls just like 
>> OS X version of Swift does. This will also allow the new Swift platform to 
>> take full advantage of the AppKit came with the alternative Foundation, 
>> allow porting full OS X apps to Linux a lot easier. The above also applies 
>> for porting iOS apps, if the alternative Foundation implementation also 
>> comes with their own UIKit.
>> 
>> Max_______________________________________________
>> swift-corelibs-dev mailing list
>> address@hidden
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>

smime.p7s
Description: S/MIME cryptographic signature