[ https://issues.apache.org/jira/browse/THRIFT-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288781#comment-17288781 ]
Allen George edited comment on THRIFT-5314 at 2/23/21, 1:56 AM: ---------------------------------------------------------------- I've taken a crack at this here: https://github.com/apache/thrift/pull/2337 After looking at the alternatives: # the one I proposed: https://issues.apache.org/jira/browse/THRIFT-5314?focusedCommentId=17235560&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17235560) # the flatbuffer implementation: https://github.com/google/flatbuffers/pull/6098/files I decided that comments from others were correct: the flatbuffer one was cleaner, avoided the use of a magic {{__Unknown}} and still allowed us to use basic matching. At the core, we now implement enums using the newtype idiom: Old way: {noformat} pub enum Foo { VariantOne = 1, VariantTwo = 2. ... } {noformat} New way: {noformat} pub struct Foo(pub i32); impl Foo { pub const VARIANT_ONE: Foo = 1; pub const VARIANT_TWO: Foo = 2; pub const ENUM_VALUES: &'static [Self] = &[Self::VARIANT_1, Self::VARIANT_2]; ... } {noformat} I've also implemented {{std::convert::From}} for some types. Please note that to conform to the Rust style guide enum variants are now in uppercase as opposed to camelcase. Whenever possible I prefer to use Rust's default conventions. cc [~rdettai] was (Author: allengeorge): I've taken a crack at this here: https://github.com/apache/thrift/pull/2337 After looking at the alternatives: # the one I proposed: https://issues.apache.org/jira/browse/THRIFT-5314?focusedCommentId=17235560&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17235560) # the flatbuffer implementation: https://github.com/google/flatbuffers/pull/6098/files I decided that comments from others were correct: the flatbuffer one was cleaner, avoided the use of a magic {{__Unknown}} and still allowed us to use basic matching. At the core, we now implement enums using the newtype idiom: Old way: {noformat} pub enum Foo { VariantOne = 1, VariantTwo = 2. ... } {noformat} New way: {noformat} pub struct Foo(pub i32); impl Foo { pub const VARIANT_ONE: Foo = 1; pub const VARIANT_TWO: Foo = 2; pub const ENUM_VALUES: &'static [Self] = &[Self::VARIANT_1, Self::VARIANT_2]; ... } {noformat} I've also implemented {std::convert::From} for some types. Please note that to conform to the Rust style guide enum variants are now in uppercase as opposed to camelcase. Whenever possible I prefer to use Rust's default conventions. cc [~rdettai] > Enum forward compatibility > -------------------------- > > Key: THRIFT-5314 > URL: https://issues.apache.org/jira/browse/THRIFT-5314 > Project: Thrift > Issue Type: Bug > Components: Rust - Compiler, Rust - Library > Affects Versions: 0.13.0, 0.14.0 > Reporter: Remi Dettai > Assignee: Allen George > Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It seems that enums in the Rust implem are not forward compatible. As Thrift > enums are mapped 1:1 to Rust enum, if a newer Thrift definition adds a case > to an enum, an error will be returned when parsing the message. > Is this intended? Is there a workaround? > (We met this problem in the Rust parquet implem: > https://issues.apache.org/jira/browse/ARROW-10553) -- This message was sent by Atlassian Jira (v8.3.4#803005)