I'm starting using thrift interfaces in rust and I've been surprised to discover that thrift enums are not generated as rust enums.
The following thrift enum
is currently rendered as
The generated code poses, in my view, some limitations as well as it does not use the powerful rust compiler capabilities:
- having a struct instead of enum removes the capability of the compiler to verify for exhaustive matching. The code below would compile
- we allow creating un-existing enums from code
I would have expected that TryFrom<i32> was implemented and not the infallible form From<i32>
- we do not allow creating enums from variant names (but we do it from enum "binary" value)
I do see that the conversion from rust enum to rust struct was done in
THRIFT-5314 for forward-compatibility but I'm wondering if that is the best way forward to ensure that we can levarage what the rust ecosystem can provide us.
This is mostly meant to lift developers from some tedious and error-prone checks which the compiler knows how to do.
NOTE: Working of a wide code-base and depending on thrift definition of thrid part services makes very hard to keep track of all the changes and having the compiler reporting the issues is a non-negligible advantage.
How could we move forward without impacting way too much on the current experience?
My idea would be to have back enum variants and in order to have backward/forward capabilities I would suggest the introduction of a sentinel enum variant (as using Result<HttpStatusCode, ::fbthrift::Error> does not look appealing to most)
Before eventually moving forward with updating the compiler to support the new schema (and I can be doing so) I would like to have a sort of discussion in order to avoid investing time toward a non-acceptable/non-ideal direction.