[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user yurikoles commented on the issue: https://github.com/apache/thrift/pull/1084 Hi @apocolipse, Please consider taking into account usage of reserved keywords in *.thrift files. For example back end developers may use field with name `description` in their structures. And this same keyword then redefined in generated extension file. This causes compile errors. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1084 Okay, so I could merge this, but I need to know (since I've never used cocoa, swift, or any of the apple stuff really): * Are there breaking changes? * Are they documented? * Is it already running in the cross test or is that future work? * Can this be exercised in the Travis CI build environment? (make check, make cross?) * Can I add swift support to Ubuntu Xenial and Artful? * What minimum and maximum versions are known supported? * Has the LANGUAGES.md file been updated? * Has the build/docker/README.md file been updated? * Is this supposed to replace the cocoa implementation? Should that be removed? I can make some of these changes as part of finalization. Thanks. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 @JacopoMangiavacchi Server side already works using something like Perfect or Zewo, I already have separate server adapters for them https://github.com/apocolipse/TPerfectHTTPServer I'd advise making Swift-Nio support separate as well to ensure better compatibility. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user JacopoMangiavacchi commented on the issue: https://github.com/apache/thrift/pull/1084 I tested this PR and I see it already support also Swift 4.0 and I'm adding Swift-Nio support for easily implement also the server side. Any update on this merge ? Thanks a lot ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user jorgeazevedo commented on the issue: https://github.com/apache/thrift/pull/1084 Any movement on this? I'd love to see this merged. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1084 I would recommend the original commenters chime in as the requested work was done; this should be SQUASHED (nobody wants to cherry-pick 84 commits) and rebased on master and if it passes CI clean, definitely good towards merging it. @nsuke and @ChristopherRogers both commented in the past. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user tbartelmess commented on the issue: https://github.com/apache/thrift/pull/1084 Any movement on this? I'd love to see this merged. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 @nsuke hah good catch, bad habits from other languages ;) Fixed ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 @nsuke requested cleanup completed ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user nsuke commented on the issue: https://github.com/apache/thrift/pull/1084 This replaces current Swift2 generator/lib with new one which supports Swift3. The current one is still kept as option `swift:cocoa`, though. Swift 2 has been not usable with latest XCode for months now so it makes sense to me to land this to master. Reviews have been done by contributors before, although a few more cleanup might be needed. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1084 What needs to happen next to move this forward? ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 Also, to anyone using this, I'm making a pretty decent sized change right now to how `TEnums` work with Swift Enums. Backstory is that Swift enums are overly opinionated and don't work well if a new enum value is added to a service and the client hasn't updated. Other languages handle this pretty easily since enums are just Ints to them, they simply read and store the value even if it doesn't match a case. Since Swift's enums are finite and opinionated, and not backed by Ints, this posed a bit of a challenge. I initially designed the TEnums to be RawRepresentable Int32 since it just made sense at the time, this let the library handle read/write generically and the generator only needed to declare the cases and an empty init case. The problem arose when we saw it failing when new values came in. Granted it was designed to do so, but we needed a way internally to gracefully handle that. As a replacement, I'm removing the RawRepresentable/Int32 requirement on TEnums, and removing the protocol read from the library as well, they will retain a rawValue and init(rawValue:) to facilitate serialization and maintain compatibility with code that may be already using those, but they're no longer inherently RawRepresentable. The reason for this decision was to add an `.unknown(Int32)` case that retains the extra value. This is an opt-in case, so you'll need to use the generator flag `safe_enums`, but this way you don't lose that information, and in the likely event you'll pull something that has an unknown enum value and then need to send it back to a service, you'll retain the appropriate value and maintain compatibility between server/client version mismatch. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user fumoboy007 commented on the issue: https://github.com/apache/thrift/pull/1084 Yeah, itâs implemented in Swift 4.  --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 Its just a proposal so far, i don't think it'll be implemented for Swift 3 (but i havent been keeping close track, correct me if i'm wrong) It'll make more sense to do once Swift4 drops and SPM is beefed up. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user fumoboy007 commented on the issue: https://github.com/apache/thrift/pull/1084 > SE-0162 [ https://github.com/apple/swift-evolution/blob/master/proposals/0162-package-manager-custom-target-layouts.md ] added API for controlling where the source files for each target should be found. This allows SwiftPM to support source trees that don't conform to the standard package layout conventions. Can we take advantage of this so that people can use the library from the official repo? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 @gotev feel free to contribute anything that was mentioned there. Its otherwise code complete (and likely better supported than the already merged Swift2 and Cocoa/Obj-C generators), I will contribute more to tests as I can but its not high priority for me right now. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user gotev commented on the issue: https://github.com/apache/thrift/pull/1084 @jeking3 @apocolipse What it's left to be done for this pull request to be merged? I can provide some help. Is [this](https://github.com/apache/thrift/pull/1084#issuecomment-289279668) everything it's needed? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1084 None that I know of. What you can do is: 1. Make sure language support is in the Dockerfile for the ubuntu and debian builds. 2. Look for CROSS_LANGS in the top level Makefile.am. That should lead you to the rest. 3. You will need a TestServer and TestClient implementation; you can look in test/cpp or test/perl for example implementations. You will probably need a new test/ subdirectory for swift. 4. Make cross until it works. If a test reliably fails (and is supposed to) put it into the known test failures file by running "test.py -U merge" from the test directory after running make cross. Note that adding to CROSS_LANGS will also run the cross feature tests as well, which are in test/features. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 @jeking3 no, any docs on whats needed for that? I can add it in. The old Cocoa+Swift generator was lacking here as well. (As is the Obj-C Cocoa generator) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1084 Are these changes integrated into the "make cross" cross-language validation suite? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 Update 2/28/2017: Old Swift generator and new merged into one, Old generator under `cocoa` option, `promise_kit` option only available for old generator as well. I don't have any Swift 2.x projects so i can't really test, but if anyone else wants to spot check code and test against old versions that'd be great. I've left the old swift generator CC file in tact (moved to `*.cc..old`), and spaced out things such that it lines up with the new code line for line for comparison. Next and last steps to make this production ready IMO is namespacing, I'm going to add an option to namespace by splitting into subdirectories. Actually configuring projects will be left up to the developer. I'll add some output describing how to do it in SPM, but injecting the targets into SPM or Xcodeproj are beyond the scope of Thrift so for now the only thing namespacing will do is place source files in their own namespace relative directory, generate imports when necessary, and appropriately namespace types. Any suggestions or input are welcome. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 @nsuke I've removed the attribution, will keep it in my personal Lib repo thats used strictly for SPM integration. Fixed the error codes you mentioned above. I'll go ahead and merge the old cocoa generator in and put it behind a flag. Ideally, users leveraging existing Swift 2.x Cocoa bindings are using Cocoapods, and have a lock to the specific commit they're using. This isn't always the case, but should serve at least a basic level of protection on their client/library dependency side. From the Generator's perspective, it will be completely broken unless they checkout the most recent commit before I merge them (or change any build steps to use the new generator). In terms of their existing code if they're extending the library or inheriting from it, some of it may break given some of the interfaces have changed towards Value-typed interfaces. Extensions should for the most part operate properly so long as they're not calling changed interfaces. All of this is of course purely speculative as I've not gone through the process of trying to migrate. Long story short however there should be facilities to hit old lib/generator when needed and given Swift is compiled, migrating code over shouldn't introduce any breaking changes or unexpected behaviors. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user fumoboy007 commented on the issue: https://github.com/apache/thrift/pull/1084 Woah, nice! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue:
https://github.com/apache/thrift/pull/1084
Update:
I've modified the generated Async clients to use a new `TAsyncResult`
parameter for callbacks rather than Optional Return/Error tuples. Short
version of why is that those parameters are always mutually exclusive, and
there's no really good way to have a non-optional return or throw pattern for
async.
With the `TAsyncResult`, non-optional return values are encapsulated
within a throwing func in the enum, such that you can handle your do/catch
block in a callback. Consider the following example:
```swift
/// normal: public func hello() throws -> String
do {
let world = try hello()
} catch let e { handle(e) }
/// async: public func hello(completion: @escaping (TAsyncResult)
-> Void)
hello() {
do {
let world = try $0.value()
catch let e { handle(e) }
}
```
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 I've created 2 separate HTTP Servers using external libraries and made them available to play with https://github.com/apocolipse/TZewoHTTPServer and https://github.com/apocolipse/TPerfectHTTPServer Their interface is identical to the TSocketServer included, so they can be quickly and easily swapped out to test differences between them. Created as separate libs to avoid no external dependency requirement for Thrift. Apple has announced a Server API team, so hopefully in the future we can have Swift STD type httpservers built-in, but for now this will do. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user ChristopherRogers commented on the issue: https://github.com/apache/thrift/pull/1084 I have not. ð --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 @fumoboy007 so for clients you should be doing something like this: ```swift let factory = THTTPSessionTransport.Factory(url: serviceURL) let client = HermesAsyncClient(with: TBinaryProtocol.self, factory: factory) ``` For servers, its all about the server, no need to have an async processor I'll need to update the Perfect HTTP Server example I have on my github for HTTP servers, but basically the setup is something like this (same as TSocketServer: ```swift let server = try? TSocketServer(port: 9090, service: MyConcreteService(), // your implementation of thrift service inProtocol: TBinaryProtocol.self, outProtocol: TBinaryProtocol.self, processor: MyServiceProcessor.self) // generated service processor ``` Since it leverages generics, each request creates its own processor rather than re-using the same one over and over (If you look at the TSocketServer impl, you'll see something like ```swift let processor = Processor(service: self.serviceHandler) processor.process(on: inproto, outProtocol: outproto) ```) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user fumoboy007 commented on the issue: https://github.com/apache/thrift/pull/1084 I donât see a `[MyService]ProcessorAsync` in the generated code. How do I handle requests in an asynchronous manner? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user fumoboy007 commented on the issue: https://github.com/apache/thrift/pull/1084 Oh I didnât know about the `async_clients` option⦠thanks! ð¬ --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 @fumoboy007 There is `TAsyncClient` in TClient.swift as well as `TAsyncTransport/Factory` in TTransport.swift, and the generator will generate async clients properly (`--gen swift_3:async_clients`), for servers, the design I've seen so far is that they're asynchronous by creating new transports for each request for an async server, so its incumbent on the base thrift server implementation to handle async code, in which the simple socket server I've included should handle it fine, as well as the Perfect server example I posted in the readme should work as well. Can you elaborate on anything more that you'd like to see? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user fumoboy007 commented on the issue: https://github.com/apache/thrift/pull/1084 One major issue I encountered is the async support. There doesnât seem to be an asynchronous `TProcessor`/`TProtocol`/`TClient` API in the base/generated code. Async support is important for high-efficiency server applications. (At least until [SR-2905](https://bugs.swift.org/browse/SR-2905) is implemented for Linux.) I can explain this in more detail if desired. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 @fumoboy007 @ChristopherRogers Have you all found any other outstanding issues that need addressing? @nsuke @kdubb What final steps do we need to do to get this into the official Thrift codebase? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user fumoboy007 commented on the issue:
https://github.com/apache/thrift/pull/1084
```
Compile Swift Module 'Thrift' (37 sources)
/Users/â¦/Packages/Thrift-1.0.0/Sources/TSet.swift:22:70: warning:
'IndexableBase' is deprecated: it will be removed in Swift 4.0. Please use
'Collection' instead
public struct TSet : Collection,
IndexableBase, ExpressibleByArrayLiteral, Hashable, TSerializable {
^
```
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue:
https://github.com/apache/thrift/pull/1084
@ChristopherRogers @fumoboy007 I implemented union support with enums,
here's an example of generated code:
```
union TestUnion {
1: i32 data,
2: string message,
3: bool success
}
```
```swift
public enum TestUnion {
case data(val: Int32)
case message(val: String)
case success(val: Bool)
}
public func ==(lhs: TestUnion, rhs: TestUnion) -> Bool {
return {
switch (lhs, rhs) {
case (.data(let lval), .data(let rval)): return lval == rval
case (.message(let lval), .message(let rval)): return lval == rval
case (.success(let lval), .success(let rval)): return lval == rval
default: return false
}
}()
}
extension TestUnion : CustomStringConvertible {
public var description : String {
var desc = "TestUnion."
switch self {
case .data(let val): desc += "data(val: \(val))"
case .message(let val): desc += "message(val: \(val))"
case .success(let val): desc += "success(val: \(val))"
}
return desc
}
}
extension TestUnion : Hashable {
public var hashValue : Int {
let prime = 31
var result = 1
switch self {
case .data(let val): result = prime &* val.hashValue
case .message(let val): result = prime &* val.hashValue
case .success(let val): result = prime &* val.hashValue
}
return result
}
}
extension TestUnion : TStruct {
public static var fieldIds: [String: Int32] {
return ["data": 1, "message": 2, "success": 3, ]
}
public static var structName: String { return "TestUnion" }
public static func read(from proto: TProtocol) throws -> TestUnion {
_ = try proto.readStructBegin()
var ret: TestUnion?
fields: while true {
let (_, fieldType, fieldID) = try proto.readFieldBegin()
switch (fieldID, fieldType) {
case (_, .stop):break fields
case (1, .i32): ret = TestUnion.data(val: try
Int32.read(from: proto))
case (2, .string): ret = TestUnion.message(val:
try String.read(from: proto))
case (3, .bool):ret = TestUnion.success(val:
try Bool.read(from: proto))
case let (_, unknownType): try proto.skip(type: unknownType)
}
try proto.readFieldEnd()
}
if let ret = ret {
return ret
}
throw TProtocolError(error: .unknown, message: "Missing required value
for type: TestUnion") }
}
```
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 @nsuke I considered that when starting out, however the differences between Swift 2 and 3 are pretty dramatic that makes shared code minimal (i.e. everything in this library is Value typed, compared to the Swift/Cocoa generator). Conceptually, this /is/ the `Swift` generator, and the other one is technically Cocoa Swift. Additionally, due to limitations with SPM, sharing code might not be the most sane option. One key difference with this and the existing Swift library, this library has no intention of Objective-C interop, it is a pure Swift approach. We could argue for moving the old Swift generator to be used like `--gen cocoa:swift` which would be more appropriate in my opinion. As far as sharing code between them goes, the amount that is the same should be negligable, but packaging is the biggest concern. Cocoapods isn't overly friendly with picking/choosing source files from different locations in the file heirarchy, and SPM isn't capable of pointing at sources not in `Sources` at all (hence the need for a separate repo for the time being to leverage it with SPM). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user nsuke commented on the issue: https://github.com/apache/thrift/pull/1084 There's a substantial amount of code duplication with existing swift generator. Do you have any idea as to reducing them ? As I've never seen anyone advocating the current practice of "single big file per language", we could, for example, extract common part to another file or even introduce a swift sub directory etc. Internal structures aside, doesn't it make more sense to have a sub-option like --gen swift:3 rather than a separate language option ? CC: @kdubb for review and/or comments. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 That'll require generation of both read and write serialization code (which I try to abstract much of to the library), but its doable I suppose. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue:
https://github.com/apache/thrift/pull/1084
@ChristopherRogers Something like this?
```
union AUnion {
1: string result,
2: CustomException error
}
```
```swift
enum AUnion {
case result(val: String)
case error(val: CustomException)
}
```
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user ChristopherRogers commented on the issue: https://github.com/apache/thrift/pull/1084 I noticed you haven't special cased unions (they'll just be generated as structs.) Have you looked into adding support for this? I'd love to be able to use Swift's enums with Thrift's union types. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 @fumoboy007 thanks, thought i had the overflow ones in there, will add them back in :) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
