[
https://issues.apache.org/jira/browse/THRIFT-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235525#comment-17235525
]
Remi Dettai commented on THRIFT-5314:
-------------------------------------
I love Rusd enums so much! Sadly I am not sure that they are the way to go
here...
I've have been investigating how the problem was solved in other similar
usecases. After some debates *flatbuffer* decided to replace the generated Rust
enum with a C style representation that its closer to its internal
representation (https://github.com/google/flatbuffers/pull/6098):
{code}struct MyEnum(u16);
impl MyEnum {
// Variants are expressed as associated constants.
pub const Variant1: MyEnum = MyEnum(1);
pub const Variant2: MyEnum = MyEnum(2);
}}}
{code}
You can then match like this, which is still pretty neat:
{code}
match my_enum {
MyEnum::Variant1 => ...,
MyEnum::Variant2 => ...,
MyEnum(x) => ...,
}
{code}
As enums are pretty similar in thrift and flatbuffer (C-style), I think the
same behavior should be mimicked.
> 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
> Reporter: Remi Dettai
> Priority: Major
>
> 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)
