Definitely not an easy problem. On the wire these will both encode as the same field ID (1) and a type ID of 6 for the i16 or a type ID of 8 for the i32. Most (all?) thrift language bindings check to ensure the type ID for a field matches the expected type ID for that particular field, silently skipping past any field with mismatched type IDs.
George Chung's suggestion is the safest/cleanest approach. I had exactly this same problem where I needed to expand from i32 to i64. It was a "flag day" cutover for me, since I had control of all the clients and servers. But I can see how you frequently can't upgrade all the client code out in the wild. (Or data files, if these are persisted.) Rather than try to solve the broader problem of versioning, maybe we should consider adding optional behavior to the decoder to permit *type-promotion*when the field's on-wire type can be safely decoded into the expected type? Provided that the expected type can faithfully represent all the values of the wire type, it seems like a way to follow the "TCP" pattern of being permissive in what you receive, but strict in what you send. In terms of thrift TTypes, we could allow a decoder to promote: bool > i08 > i16 > i32 > (double or i64) This wouldn't solve every problem - like sending a response struct with an i32 field to a client than expects i16. No go there. This would be only useful in cases of having to read client input from a mixed bag of old and new clients, where the server response struct doesn't need any wider fields. I'm not sure if that is your use-case... Those using thrift for serialization to/from disk, I would imagine type-promotion could save a lot of effort in re-encoding any old files that use narrower numeric types than newer files... Thoughts?
