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 reconsidered? 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 canstring == 'true'trivially. Having"True".true? #=> false` seems a bit counterintuitive.

For some reason the true/false/nil ones seem totally make sense to me even though I'm not sure I'd use them. I'm really curious what the use case is for the String variant?