JsonElement.ToString() outputs incorrectly for JsonValueKind.False and JsonValueKind.True. The output is "False" and "True" respectively, however JSON requires that these constants are lower-case.
See ECMA-404, Section 4.
These are the three literal name tokens:
- true U+0074 U+0072 U+0075 U+0065
- false U+0066 U+0061 U+006C U+0073 U+0065
- null U+006E U+0075 U+006C U+006C
I think JsonElement.ToString() is not supposed to return a JSON value. And this behavior is explicitly called out in the documentation.
JsonElement.ToString() is not a JSON serialization method, where following the JSON spec would be the default behavior.
This behavior is intentional and called out in the documentation for the method:
For JsonValueKind.True, Boolean.TrueString is returned.
For JsonValueKind.False, Boolean.FalseString is returned.
@gregsdennis - what was the motivation for opening this issue? Are there any scenarios where you would depend on the output formatted as "true"/"false"?
Probably misunderstanding. I didn't know those docs existed. Seems like a .ToString() on something that represents JSON would output JSON.
What is the preferred method for converting a JsonElement to actual JSON?
Oh... .GetRawText()... Not very intuitive, TBH.
I agree with Greg.
The design does not appear to follow the principle of least surprise - in my personal experience I cannot think of any time I'd want to see the 'False' vs 'false' when operating in a json context.
And this surprising behavior extends to higher level functionality like string interning - perhaps I am constructing a custom Json literal - the implicit ToString call's output would be a surprise.
I would be interested in the opposite question: what scenarios require 'False' being generally more useful in json contexts? (I am not assuming there aren't any, I am genuinely curious what they are)
BTW, the documentation is a symptom, not the cause. I believe the design is what's being questioned.
Most helpful comment
I agree with Greg.
The design does not appear to follow the principle of least surprise - in my personal experience I cannot think of any time I'd want to see the 'False' vs 'false' when operating in a json context.
And this surprising behavior extends to higher level functionality like string interning - perhaps I am constructing a custom Json literal - the implicit ToString call's output would be a surprise.
I would be interested in the opposite question: what scenarios require 'False' being generally more useful in json contexts? (I am not assuming there aren't any, I am genuinely curious what they are)
BTW, the documentation is a symptom, not the cause. I believe the design is what's being questioned.