[
https://issues.apache.org/jira/browse/THRIFT-3773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041295#comment-16041295
]
ASF GitHub Bot commented on THRIFT-3773:
----------------------------------------
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.
> Swift Library
> -------------
>
> Key: THRIFT-3773
> URL: https://issues.apache.org/jira/browse/THRIFT-3773
> Project: Thrift
> Issue Type: New Feature
> Components: Swift - Library
> Reporter: Thomas Bartelmess
> Assignee: Chris Simpson
>
> 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
(v6.3.15#6346)
