Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

type_name() is not consistent with type() #1833

Closed
ignus2 opened this issue Nov 8, 2019 · 1 comment
Closed

type_name() is not consistent with type() #1833

ignus2 opened this issue Nov 8, 2019 · 1 comment
Labels
solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope)

Comments

@ignus2
Copy link

ignus2 commented Nov 8, 2019

  • What is the issue you have?
    type_name() returns "number" for both value_t::number_integer, value_t::number_unsigned, value_t::number_float. This is inconsistent with type().

  • What is the expected behavior?
    x.type_name() should return the exact string representation of the matching x.type(), as it's name implies, specifically:
    value_t::number_integer: "number_integer"
    value_t::number_unsigned: "number_unsigned"
    value_t::number_float: "number_float"

  • Did you use a released version of the library or the version from the develop branch?
    Develop, commit: 67259d6

@nlohmann
Copy link
Owner

nlohmann commented Nov 9, 2019

This is intentionally:

  • type_name() returns the name of the JSON type. JSON only defines a type number and does not make any differentiation between signed/unsigned or float/integer. This function is used in error messages for situations where a specific JSON type is expected, but a different one was found. In these situations, it is not helpful to state the specific type of a number - it is sufficient to have something like expected string, but got number.
  • type() returns an enum of the types used in the library. As you observed correctly, a JSON number can be represented by three different types internally. This function is used to define a switch to process each internal type differently, e.g. in the serialization function, where number_float needs to be treated differently than the integer types. The library does not need a textual representation of these internal types, therefore it does not offer such a function.

@nlohmann nlohmann added solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope) and removed kind: bug labels Nov 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope)
Projects
None yet
Development

No branches or pull requests

2 participants