Hi,
I've made a lot of progress on the Rust thrift generation front and
I've been able to get the C++ server and Rust client communicating for
some types. One thing really puzzles me however: T_OPT_IN_REQ_OUT
fields. Looking at the docs and other code generators it looks like
those fields are written out no matter what. Does that mean that I'm
writing a default value (empty string, empty collections, 0 for
numeric types) when they're not set? This seems very puzzling, because
the receiver can't tell the difference between sender-unset values and
values with the standard default. It's unfortunate from my point of
view because a Rust client communicating with an echo server receives
a result that doesn't match what it sent out!
An example:
struct Foo {
1: string thing;
}
Rust representation:
struct Foo {
thing: Option<String>,
}
If I don't set "thing" I have the following value to send:
let sent = Foo { thing: None }
With the OPT_IN_REQ_OUT behavior it seems I have to serialize an empty
string over the wire. As a result, when the echo server responds, I
actually get:
Foo { thing: Some("") }
This means that my simple "check that the response is exactly what I
sent out" doesn't quite work and I'll have to modify it for those
cases where I have unset fields. At any rate - just wanted to check
that my understanding of OPT_IN_REQ_OUT was right.
Thanks,
Allen
Terminal Musings: http://www.allengeorge.com/
Raft in Java: https://github.com/allengeorge/libraft/
Twitter: https://twitter.com/allenageorge/
