Numeric type classified as string

[NiN9876]

Describe the bug
Numbers with large number of digits are classified as strings

Enumerate the steps to reproduce the bug

Include a small, self-contained example if possible
Running this code

  auto parsed = jsoncons::json::parse(R"({"a": 123456789012345678901234567890})");
  std::cout << "is_string:      " << (parsed["a"].is_string() ? "Yes" : "No") << std::endl;
  std::cout << "is_string_view: " << (parsed["a"].is_string_view() ? "Yes" : "No") << std::endl;
  std::cout << "is_number:      " << (parsed["a"].is_number() ? "Yes" : "No") << std::endl;

produces the following output

is_string:      Yes
is_string_view: Yes
is_number:      Yes

What compiler, architecture, and operating system?

Visual Studio 2022 on Windows 11,
Toolset: Visual Studio 2022 (v143),
C++ Language Standard: Preview - ISO C++23 Standard (/std:c++23preview)

What jsoncons library version?

• Latest release 1.4.3
• Other release ______
• master

[danielaparker]

I think it's okay. Big numbers are stored as strings (tagged with bigint or bigdec), and any operation that can be applied to a string can be applied to them. Strings with with bigint or bigdec tags are also numbers, so operations such as as<double>() or try_as<double> are valid (with conversion taking place.) Users also have the ability to define reflection traits for their preferred big number types, and use them like as<my_big_decimal>() or try_as<my_big_decimal>().

From jsoncons' point of view, they are strings and they are numbers.

[NiN9876]

The storage type is an implementation detail which, strictly speaking, should not affect the type. If all integers were stored as strings would they have been considered strings as well?
Such ambiguity is unexpected, confusing and, in many cases, undesirable. For example, the following scheme validation code

  std::string schemaString = R"(
        {
            "$schema" : "https://json-schema.org/draft/2020-12/schema",
            "type" : "object",
            "properties" : {
                "a" : {"type" : "string"}
            }
        }
    )";
    
    auto parsed = jsoncons::json::parse(R"({"a": 123456789012345678901234567890})");
    std::cout << "is_string: " << (parsed["a"].is_string() ? "Yes" : "No") << std::endl;

    auto schema = jsoncons::jsonschema::make_json_schema(jsoncons::json::parse(schemaString));
    try
    {
      schema.validate(parsed);
    }
    catch(const std::exception& e)
    {
      std::cout << "Schema validation failed (" << e.what() << ")" << std::endl;
    }

produces this strange output

is_string: Yes
Schema validation failed (/a: Expected string, found string)

Perhaps the parser can provide an option for using stricter types with which is_string() is true only for values which satisfy the defintion in https://datatracker.ietf.org/doc/html/rfc8259: "A string begins and ends with quotation marks."?

[danielaparker]

A json_basic doesn't have a big integer or big decimal numeric type, the possible types are null, bool, int64, uint64, double, string, byte string, array, and object, and that's it. We do allow semantic tagging of these types, to capture additional meaning. And these tags do affect how values are serialized.

If Standard C++ had a std::bigdec type, like other languages do, we could have followed .Net JsonElement and introduced a decimal type. But Standard C++ doesn't. When our users end up with a large number, they want if possible to get it as a string view, so they can convert it into their own preferred large number type as efficiently as possible, with as few allocations as possible. It is is_string() that tells them whether that is possible, whether as<std::string_view>() will succeed.

Out of interest, I compared how other implementations parsed {"a": 123456789012345678901234567890} into their respective generic types. The results were:

[jsoncons (default)] {"a":123456789012345678901234567890}
[nlohmann] {"a":1.2345678901234568e+29}
[glaze] {"a":1.2345678901234568E29}
[reflect-cpp] {"a":1.2345678901234568e29}
[yyjson (default)] {"a":1.2345678901234568e29}
[yyjson (with YYJSON_READ_NUMBER_AS_RAW)] {"a":123456789012345678901234567890}

Most parsed the number into a double, losing precision. yyjson permits the option YYJSON_READ_NUMBER_AS_RAW, giving it a YYJSON_TYPE_RAW, distinct from YYJSON_TYPE_STRING. I suppose we could have supported is_raw_string(), distinct from is_string().

I do agree with you that that error message is unhelpful, I'll have a look at that.

EDIT: Although after thinking about it, I do see your point.

[danielaparker]

"Expected string, found string" will be "Expected string, found number" on master

[NiN9876]

Confirmed. Thank you!

The error rmessage is correct with any lossless_bignum option value

The return value of is_string has also been fixed - it returns false when parsed with option lossless_bignum(false)

is_string: No
Schema validation failed (/a: Expected string, found number)