Why not coerce string 1 and 0?

[shmax]

Hi folks, I just have a question for you. I'm a contributor to a similar project as this one, written in PHP. We've recently added support for type coercion, and a few days ago someone submitted a PR with the aim of supporting coercion of string "1" and "0" to boolean.

jsonrainbow/json-schema#345

I've been arguing against it, but with a flawed rationale (I was unaware that http_build_query converts true and false to string 1 and 0).

I've studied your coercion grid carefully, and if I understand correctly you do NOT coerce string 1 and 0 to boolean. I was wondering if you could explain your reasoning? Thanks much!

[epoberezkin]

@shmax The reason is that as it is all coercions are reversible to the same starting value. If you allow coercing "0" to false then the reverse coercion will have a different result ("false" instead of "0"). It may have unexpected effects when schemas have multiple branches with different types expected in different branches. Such unexpected effects may still happen when there is more then one coercion (e.g. "0"->0->false->"false") but they are less likely.

[JanTvrdik]

I don't think I understand why do you need to reverse the coercion at all. Can't you just remember the original value?

[epoberezkin]

Consider the schema:

{
  "anyOf": [
    { "type": "boolean", "enum": [true] },
    { "type": "string", "pattern": "^[0-9]+$" }
  ]
}

With my grid this schema passes with "0" regardless whether coercion is on or off. With your coercion idea it would fail WITH coercion turned on. But it's the opposite to what is expected from coercion - to pass when it would fail without it.

Remembering the original value is not trivial - coercion just mutates data in place.

[JanTvrdik]

With your coercion idea it would fail WITH coercion turned on.

No, I always assumed that it would be properly implemented. https://github.com/justinrainbow/json-schema does not support coercion with multiple types at all, so it does not matter really.

coercion just mutates data in place

But you can remember the place (in PHP for example with reference to the value, in JS probably with reference to parent object and name of property).

[shmax]

@epoberezkin I just tried it, and you're absolutely correct. Thanks very much for a very insightful and delicate point.

[epoberezkin]

does not support coercion with multiple types at all, so it does not matter really.

Ajv supports it. It coerces to the first possible type in the list.

But you can remember the place (in PHP for example with reference to the value, in JS probably with reference to parent object and name of property).

Yes, sure you can... It just seems like one more complication where there are quite a few already. Particularly in my case - Ajv compiles schemas to JavaScript, so all this logic would have to happen in generated code. Also it seems to be introducing some non-determinism where you'll have to make some arbitrary choices whether to pass or to fail (too late to come up with a specific example :), I may be wrong here, but the first reason is strong enough for me not to do it anyway)...