Allow 1 and 0 as booleans?

[Grinnz]

Describe the feature: #22200 and #26389 removed support for lenient booleans, which makes a lot of sense. Allowing arbitrary values as booleans is asking for silent mistakes like misspelling 'false'. However, the values 1 and 0 (or exact strings "1" and "0") are widely used or accepted as booleans in many programming languages, and for example in Perl and SQL are a generally used form of boolean since the languages have no native booleans. I don't feel that it would cause any of the same issues as the previous lenient booleans if these exact values were additionally allowed, and it would be convenient for instances where one is using various components with different boolean representations, in the case where '0' and '1' are the only representations that can be transparently used across all systems.

[clintongormley]

@Grinnz As the author of the Perl client, I felt similarly and have long defended truthy/falsey values, until I realised that 0 is true in ruby. When you start looking at other languages, you realise that there is a mishmash of what is considered true vs false, so whatever you choose, it's going to be wrong (and thus surprising and confusing) for somebody.

This led me to put my weight behind strict booleans. We're not going to add 0 and 1 as accepted values for the reason stated above (why choose the Perl way instead of the Ruby way?).

The Perl client converts truthy and falsey values to true/false in the query string parameter handling, and you can use JSON::PP::True and JSON::PP::False (or \0/\1) in the request body.

[Grinnz]

I think you may have misinterpreted. I am not arguing for the "Perl way" or "truthy/falsey values", I agreed that removing these was a good idea. I am arguing specifically for 1 and 0 which are used as booleans in more than just Perl - SQL (at least MySQL) and C come to mind. Ruby has native booleans so would not need to use these. (I am also well aware of how to generate booleans in JSON.)

[clintongormley]

it would be convenient for instances where one is using various components with different boolean representations, in the case where '0' and '1' are the only representations that can be transparently used across all systems.

Except it would fail for Ruby. If you're talking interoperability then Ruby's native booleans don't count. That's my point. This is why we scaled it right back to the most basic.