thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (THRIFT-3773) Swift Library
Date Fri, 06 Apr 2018 18:59:00 GMT


ASF GitHub Bot commented on THRIFT-3773:

apocolipse commented on issue #1084: THRIFT-3773 Swift 3 Native Library
   Hey @jeking3 I'll answer as best I can given i haven't done much with Thrift in a while
:) my coworker has taken up much of the Thrift work with Swift internally at my company.
   - No/Yes?  The compiler is written to allow for the Old Cocoa/Swift with a compiler flag,
so anyone still using swift 1 or 2 should still be able to use the Cocoa style generator but
will have to use a compiler flag
   - I don't believe thats documented anywhere
   - No tests written for this, that is future work
   - Should be exercisable in Travis though no tests currently
   - I'm not sure where the Swift compiler support for Xenial and Artful currently is, but
should be available.
   - Given backwards compatibility with Cocoa/Swift generator this should work with all Swift
versions v1 through v4 (for Swift 1 and 2, the Cocoa library which is Obj-C is required along
with the cocoa flag when generating code, for Swift 3+ the dedicated Swift library is required)
   - has not been updated
   - build/docker/ have not been updated
   - The cocoa implementation is separate from this implementation.  The Cocoa compiler/libraries
exist for Obj-C, and Swift 1 & 2, whereas Swift 3+ operate independently without Cocoa
(as Swift 3 and up can run on Linux without Obj-C runtime/libraries).  That being said the
old Swift/Cocoa compiler is "gone/removed" and there is "only 1 Swift compiler" given the
old Swift/Cocoa compiler is integrated in this as a compiler flag
   - Given this is a full rewrite it will not play nice with #1002, though since that PR is
related to the Swift/Cocoa compiler and that has been integrated for backwards compatibility
that PR can be rewritten to work with this.  My comments on that PR still stands, the style
of "Namespacing" used there by prefixing class names is a Cocoa convention that is improper
in Swift, This version does proper "namespacing" for Swift by putting generated files in namespaced
folders which should then be imported as separate modules, adhering to Swift's module namespacing
conventions, however for the Swiftv1+2/Cocoa side its an acceptable pattern.

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

> Swift Library
> -------------
>                 Key: THRIFT-3773
>                 URL:
>             Project: Thrift
>          Issue Type: New Feature
>          Components: Swift - Library
>            Reporter: Thomas Bartelmess
>            Assignee: Chris Simpson
>            Priority: Major
> We already have the option to generate Swift code in the Cocoa compiler, however large
parts of the (Objective-C) Cocoa Library still depend on Cocoa and  Objective-C.
> It would be good to have a native Swift library that doesn't depend on the Cocoa libraries.
> Design goals:
> - Fully compatible with the code that is currently generated by the Cocoa compiler (both
Objective-C and Swift).
> - Ability to run on Linux
> - Pure Swift, no Objective-C code.
> - No dependencies on closed source apple libraries
> - Keep the same interface, so that the library is compatible with the code the current
cocoa compiler generates
> - Better server support that the current Objective-C library.
> - Follow the new Swift packaging format to be compatible with the Swift Package manager

This message was sent by Atlassian JIRA

View raw message