Why isConvertibleTo never supported int64Value?

[j1elo]

I'm maintaining some old code that gets auto-generated from a FreeMarker template, like this (simplified):

if (!jsonValue.isMember("${property.name}") ||
    !jsonValue["${property.name}"].isConvertibleTo(Json::ValueType::${property.type})) {
  throw Error("'${property.name}' should be of type ${property.type}");
}

The ${property.name} and ${property.type} placeholders get filled with some field definitions that are read from an external file (and are applied to the template, by a Java program). This template works fine for field definitions like name: "myString", type: "stringValue" or name: "myArray", type: "arrayValue", but for int64 types like name: "myInt64", type: "intValue", the isConvertibleTo() function has a fatal limitation, as described in the NEWS file:

isConvertibleTo(intValue) may return false even if type() == intValue. This is because the value may have been constructed with a 64-bit integer larger than maxInt, and calling asInt() would cause an exception. If you're writing new code, use isInt64 to find out whether the value is exactly representable using an Int64 [...].

Thus isConvertibleTo() was rendered into a subpar way to check for the value type.

I'd love a bit of context around this, to have more understanding of the topic, so my question is: Why ValueType never received a new couple types ValueType::int64Value and ValueType::uint64Value, with their corresponding code inside isConvertibleTo()?

Even if it's just for coherency and to offer a homogeneous API, these two additions would have made sense, and seems to me that they would have been much better than having to second-guess the return value of isConvertibleTo().