Feature #21556: Add true? and false? methods to NilClass, TrueClass, FalseClass, and String

• Status: Feedback
• Assignee: -
• Target version: -

[Phalado (Raphael Cordeiro)]

Sometimes we need to check for an exact true or false value. This can be a string or a boolean value.

Usually, what I do to solve this is something like value.to_s == true, this way covering for strings, booleans, and nil values.

The idea of these new methods is to check for the exact value, being it a String, a Boolean, or even a Nil value.

This is the result obtained:

# String

'true'.true? # true
'false'.true? # false
''.true? # false

'true'.false? # false
'false'.false? # true
''.false? # false

# Boolean

true.true? # true
true.false? # false

false.true? # false
false.false? # true

# Nil

nil.true? # false
nil.false? # false

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Feedback

Phalado (Raphael Cordeiro) wrote:

Sometimes we need to check for an exact true or false value. This can be a string or a boolean value.

For what situation, and why mixing strings and true/false?
It sounds like depending on applications/libraries.

[Phalado (Raphael Cordeiro)]

nobu (Nobuyoshi Nakada) wrote in #note-1:

Phalado (Raphael Cordeiro) wrote:

Sometimes we need to check for an exact true or false value. This can be a string or a boolean value.

For what situation, and why mixing strings and true/false?
It sounds like depending on applications/libraries.

Data received on requests and JSON conversion. It's not unusual that a Boolean is converted to a String, or users end up filling in as a String instead of a Boolean.

[austin (Austin Ziegler)]

Phalado (Raphael Cordeiro) wrote in #note-2:

nobu (Nobuyoshi Nakada) wrote in #note-1:

Phalado (Raphael Cordeiro) wrote:

Sometimes we need to check for an exact true or false value. This can be a string or a boolean value.
For what situation, and why mixing strings and true/false?
It sounds like depending on applications/libraries.
Data received on requests and JSON conversion. It's not unusual that a Boolean is converted to a String, or users end up filling in as a String instead of a Boolean.

If you're checking a string for the value "true", you're not checking for an exact true or false value. This is a data conversion applicable to an application, library, or framework (that is, it might be a viable feature for ActiveSupport) but I don't believe it belongs as part of the language core.

I'm mostly doing Elixir these days where in a library I made I have explicitly handled this with an as_boolean(value, options) conversion where the options include choices like:

• which values are truthy (by default true or 1)
• which values are fasly (the inverse of truthy and cannot be specified with truthy)
• a default value (false by default)
• and whether values should be downcased (TRUE would be truthy)

Simply saying value.true? isn't something that the language should be specifying. What would the value of 0.true? be (it depends; in shell scripts, 0 is success; in C, 0 is false; in Ruby 0 is truthy because it's not false or nil).

I'm very negative on this for core.

[shan (Shannon Skipper)]

I wonder if the inclusion of the String variant could be considered again even though it has been merged? Is there a domain where "true" and "false" Strings are used? The Rails variant trying to support env vars makes more sense to me than string == 'true' test since you can string == 'true' trivially. Having "True".true? #=> false seems a bit counterintuitive.

I think the true/false/nil ones seem totally make sense.

Edit: Rereading the issue, I think I somehow missed that the point of the feature was bool and String both being supported. Sorry for the noise. I'm still curious if a mix of String of exactly true/false Strings and bool is something typical?

[Phalado (Raphael Cordeiro)]

austin (Austin Ziegler) wrote in #note-3:

Phalado (Raphael Cordeiro) wrote in #note-2:

nobu (Nobuyoshi Nakada) wrote in #note-1:

Phalado (Raphael Cordeiro) wrote:

Sometimes we need to check for an exact true or false value. This can be a string or a boolean value.
For what situation, and why mixing strings and true/false?
It sounds like depending on applications/libraries.
Data received on requests and JSON conversion. It's not unusual that a Boolean is converted to a String, or users end up filling in as a String instead of a Boolean.

If you're checking a string for the value "true", you're not checking for an exact true or false value. This is a data conversion applicable to an application, library, or framework (that is, it might be a viable feature for ActiveSupport) but I don't believe it belongs as part of the language core.

I'm mostly doing Elixir these days where in a library I made I have explicitly handled this with an as_boolean(value, options) conversion where the options include choices like:

• which values are truthy (by default true or 1)
• which values are fasly (the inverse of truthy and cannot be specified with truthy)
• a default value (false by default)
• and whether values should be downcased (TRUE would be truthy)

Simply saying value.true? isn't something that the language should be specifying. What would the value of 0.true? be (it depends; in shell scripts, 0 is success; in C, 0 is false; in Ruby 0 is truthy because it's not false or nil).

I'm very negative on this for core.

Well, the idea is to recognize true/false values, ignoring truthy/falsy values because of JSON.

I also think this is something very 'Ruby' to do, like the method .zero? just to check if a value is equal to zero.

But I respect your opinion and truly appreciate it.

[Phalado (Raphael Cordeiro)]

shan (Shannon Skipper) wrote in #note-4:

I wonder if the inclusion of the String variant could be considered again even though it has been merged? Is there a domain where "true" and "false" Strings are used? The Rails variant trying to support env vars makes more sense to me than string == 'true' test since you can string == 'true' trivially. Having "True".true? #=> false seems a bit counterintuitive.

I think the true/false/nil ones seem totally make sense.

Edit: Rereading the issue, I think I somehow missed that the point of the feature was bool and String both being supported. Sorry for the noise. I'm still curious if a mix of String of exactly true/false Strings and bool is something typical?

The idea here came when working with JSON from requests and, especially, Active Admin. Users sometimes fill boolean values as true, other times as "true", which can be a problem if you are expecting a boolean or a string specifically. Also, a nil value can be considered 'false', which is not always the case when treating data.

So, instead of checking for nil, converting it to string and, in the end, checking if it'1s equal to 'true' or 'false' (kinda converting to boolean) I came with this, where Strings, Booleans and Nil values can live together in harmony.