0 should not be considered equal to False

[Zac-HD]

I'm working on some schema canonicalisation and intersection logic for hypothesis-jsonschema, and encountered the surprising-to-me property that jsonschema sometimes considers 0 == False (and similarly 1 == True):

# All of these pass:
validate(0, {"just": False})            # 0 == False
validate(False, {"enum": [0.0]})        # 0.0 == False
# Fails, "On instance: [0, 0]", despite `unbool` logic
validate([0, False], {"uniqueItems": True})

According to the core spec, instances are only equal if they are of the same type.

(and there is only one number type in JSON, so 1 == 1.0)

The validation spec doesn't actually say anything about how value equality (ctrl-f "equal") should be defined, but I certainly found this surprising and the uniqueItems message convinced me to report it.

[Julian]

The latter likely related to your still-open #529.

I actually... don't have an opinion yet :D, have to think about what I expect.

Obviously the inconsistency is wrong, but not sure which to expect. I guess slightly leaning towards them always being equal, but have to think.

Thoughts welcome of course :), and yeah thanks for filing obviously!

[Zac-HD]

It's not obvious, thats for sure! My preference would be to treat all numeric zeros (integer or float) as equal, but booleans as unequal to numbers. Either way, it's a question that should be addressed by the specification since it does change the semantics.

Treating booleans as unequal to numbers unlocks several nice optimisations in the logic I usr for canonicalising schemas and calculating intersections - with I can treat them as enums; without I have to keep and track the type information too. Not sure if that will convince anyone but me though 😅

Final fun fact: IEEE754 allows you to represent negative zero, but it can't be serialised as JSON. So hypothesis-jsonschema already has special handling for zeros, even before this issue!

[gregsdennis]

Having 0 synonymous to false is certainly a language-specific thing. It is in many C-based languages, but notably not in C# (or any .Net language). I imagine there are other such cases in other strongly-typed languages where integers and booleans are distinct concepts.

JSON Schema as a spec has historically (and will remain) language-agnostic, so I disagree with this being in the spec. It would require that languages that distinguish between integers and booleans (e.g. C# and other .Net languages) would have to support something that is contrary to the language/framework in which their written, which would be a poor developer experience.

If an implementation that is written in a language that supports equivalency between integers and booleans wishes to support this, then I see it as an augmentation over JSON Schema and should be documented as such.

[Zac-HD]

JSON Schema as a spec has historically (and will remain) language-agnostic, so I disagree with this being in the spec. It would require that languages that distinguish between integers and booleans (e.g. C# and other .Net languages) would have to support something that is contrary to the language/framework in which their written, which would be a poor developer experience.

The options are that either:

• Jsonschema has different equality semantics to (some) host languages, or
• There are instances which may or may not validate against a given schema depending on which language you're using.

The former is certainly unintuitive, but the latter is a disaster for interoperability: imagine the developer experience of an instance passing validation on the (JS) frontend, but failing at the (C#) backend with the same schema!

[Julian]

For what it's worth, the latter is *already* the case :) -- e.g., take a language with no ability whatsoever to represent false, which instead just deserializes falses to 0. E.g. a C89 implementation presumably. There are other examples (in the spec and otherwise, of languages that don't have separate integer and float types, say). But the spec already acknowledges such a thing:

JSON Schema is programming language agnostic, and supports the full range

of values described in the data model. Be aware, however, that some languages and JSON parsers may not be able to represent in memory the full range of values describable by JSON.

…

On Mon, Jul 1, 2019 at 8:43 PM Zac Hatfield-Dodds ***@***.***> wrote: JSON Schema *as a spec* has historically (and will remain) language-agnostic, so I disagree with this being in the spec. It would require that languages that *distinguish* between integers and booleans (e.g. C# and other .Net languages) would have to support something that is contrary to the language/framework in which their written, which would be a poor developer experience. The options are that either: - Jsonschema has different equality semantics to (some) host languages, or - There are instances which *may or may not validate* against a given schema depending on which language you're using. The former is certainly unintuitive, but the latter is a disaster for interoperability: imagine the developer experience of an instance passing validation on the (JS) frontend, but failing at the (C#) backend with the same schema! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#575>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACQQXTVACLRNVC42OTXML3P5KQDVANCNFSM4H4OGS4Q> .

[Zac-HD]

My problem here is that "different languages, even among those that distinguish booleans from integers, have different validation semantics" is the opposite of a language-agnostic specification.

To put that another way, a language-agnostic spec would have the same semantics regardless of language, so that whether an instance validates against some schema is always independent of which language is being used to validate it. I think this is a very important property for a validation spec to have.

[Julian]

Uh another funny example of this by the way, or at least a slightly related one -- {"oneOf": [{"format": "date"}, {}]} which does various things not only across languages but potentially across implementations or here the same implementation :) (see e.g. #585, #482, and countless other users finding this out).

[Zac-HD]

A-ha! Looking in the core specificiation (instead of the validation spec):

Two JSON instances are said to be equal if and only if they are of the same type and have the same value according to the data model. Specifically, this means: ... both are numbers, and have the same mathematical value; or ...

So 1 == 1.0, but 1 != True.