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.
---
