Support for long in Value.proto

[shubhamDhoble]

I am using value as well as struct in my proto object. But one of the key in the value is of type long.

Value.proto seems like:
message Value { // The kind of value. oneof kind { // Represents a null value. NullValue null_value = 1; // Represents a double value. double number_value = 2; // Represents a string value. string string_value = 3; // Represents a boolean value. bool bool_value = 4; // Represents a structured value. Struct struct_value = 5; // Represents a repeated Value. ListValue list_value = 6; } }

Can this also support long as one of its type as well?

PS. for further details on struct and value object, please check
https://github.com/google/protobuf/blob/master/src/google/protobuf/struct.proto

[acozzette]

I suspect that the reason Value doesn't contain any integer types is so that it can be compatible with JSON, which only has double-precision float as its number type. So I think we would be reluctant to add another type that would make JSON compatibility more difficult.

[flozano]

I think this is wrong.

It's not possible to store sufficiently-big long values as double.

JSON doesn't dictate "integer" or "double-precision format", JSON grammar dictates "number" as an arbitrary precision arbitrarily big decimal-or-integer number, see https://www.json.org/json-en.html and the grammars.

Right now I can't write in a Struct a big enough number (8484298990673538410) and expect it to keep its value, while in JSON I can.

Struct should support either one single type of Value which can carry all kind of numbers that a JSON can carry without loss of information (which would be backward-incompatible), or additional type(s) of Value(s) which can carry the different kind of numbers that actually can be represented in a JSON.

This decision is forcing people to represent big longs as strings in Structs, whereas in JSON they can be represented with no issue.

Please check:
#4406
#7039

and please consider reopening this issue.

I think supporting inside Struct the outcome of #7039 would be probably good enough.