I would say that the parser is broken then. Why should I not be able to
call my field "uuid"?
Am 09.09.2022 um 21:41 schrieb Duru Can Celasun:
Agreed. It seems a new reserved word is unavoidable, so let's at least prefix
it.
On Fri, 9 Sep 2022, at 18:30, Yuxuan Wang wrote:
If making it not a reserved word is infeasible, my next suggestion would be
to rename it to something like "tuuid" (similar to how we prefix t to a lot
of the names).
It would still be a big breaking change if someone have a thrift file with
a field/type named tuuid, but that's far less likely compare to the name
uuid.
On Fri, Sep 9, 2022 at 10:24 AM Yuxuan Wang <yuxuan.w...@reddit.com> wrote:
I was trying the compiler from the latest master branch, and got this
error on one of our existing thrift files:
[ERROR:/path/to/file.thrift:182] (last token was 'uuid')
The line is basically a field named uuid:
40: optional string uuid,
So I think what happens is that uuid is now a reserved word of thrift, and
we can no longer use it as the name of a field/struct/etc. (the same as we
cannot name a field "string" or "i64")
This is a big problem. This means that old thrift file no longer compiles
without modification (uuid is likely a commonly used field name right now
when we actually needs an uuid there), and renaming an existing field is
also a breaking change (it means all the code have to be changed to
accommodate the new field name).
I'm not sure how feasible it is to make it not a reserved word?
