Why is a Regexp object considered to be “falsy” in

Question

Ruby has a universal idea of "truthiness" and "falsiness".

Ruby does have two specific classes for Boolean objects, TrueClass and FalseClass, with singleton instances denoted by the special variables true and false, respectively.

However, truthiness and falsiness are not limited to instances of those two classes, the concept is universal and applies to every single object in Ruby. Every object is either truthy or falsy. The rules are very simple. In particular, only two objects are falsy:

• nil, the singleton instance of NilClass and
• false, the singleton instance of FalseClass

Every single other object is truthy. This includes even objects that are considered falsy in other programming languages, such as

• the Integer 0,
• the Float 0.0,
• the empty String '',
• the empty Array [],
• the empty Hash {},

These rules are built into the language and are not user-definable. There is no to_bool implicit conversion or anything similar.

Here is a quote from the ISO Ruby Language Specification:

6.6 Boolean values

An object is classified into either a trueish object or a falseish object.

Only false and nil are falseish objects. false is the only instance of the class FalseClass (see 15.2.6), to which a false-expression evaluates (see 11.5.4.8.3). nil is the only instance of the class NilClass (see 15.2.4), to which a nil-expression evaluates (see 11.5.4.8.2).

Objects other than false and nil are classified into trueish objects. true is the only instance of the class TrueClass (see 15.2.5), to which a true-expression evaluates (see 11.5.4.8.3).

The executable Ruby/Spec seems to agree:

it "considers a non-nil and non-boolean object in expression result as true" do
  if mock('x')
    123
  else
    456
  end.should == 123
end

According to those two sources, I would assume that Regexps are also truthy, but according to my tests, they aren't:

if // then 'Regexps are truthy' else 'Regexps are falsy' end
#=> 'Regexps are falsy'

I tested this on YARV 2.7.0-preview1, TruffleRuby 19.2.0.1, and JRuby 9.2.8.0. All three implementations agree with each other and disagree with the ISO Ruby Language Specification and my interpretation of the Ruby/Spec.

More precisely, Regexp objects that are the result of evaluating Regexp literals are falsy, whereas Regexp objects that are the result of some other expression are truthy:

r = //
if r then 'Regexps are truthy' else 'Regexps are falsy' end
#=> 'Regexps are truthy'

Is this a bug, or desired behavior?

Answer 1

This is the result of (as far as I can tell) an undocumented feature of the ruby language, which is best explained by this spec:

it "matches against $_ (last input) in a conditional if no explicit matchee provided" do
  -> {
    eval <<-EOR
    $_ = nil
    (true if /foo/).should_not == true
    $_ = "foo"
    (true if /foo/).should == true
    EOR
  }.should complain(/regex literal in condition/)
end

You can generally think of $_ as the "last string read by gets"

To make matters even more confusing, $_ (along with $-) is not a global variable; it has local scope.

---

When a ruby script starts, $_ == nil.

So, the code:

// ? 'Regexps are truthy' : 'Regexps are falsey'

Is being interpreted like:

(// =~ nil) ? 'Regexps are truthy' : 'Regexps are falsey'

...Which returns falsey.

On the other hand, for a non-literal regexp (e.g. r = // or Regexp.new('')), this special interpretation does not apply.

// is truthy; just like all other object in ruby besides nil and false.

---

Unless running a ruby script directly on the command line (i.e. with the -e flag), the ruby parser will display a warning against such usage:

warning: regex literal in condition

You could make use of this behaviour in a script, with something like:

puts "Do you want to play again?"
gets
# (user enters e.g. 'Yes' or 'No')
/y/i ? play_again : back_to_menu

...But it would be more normal to assign a local variable to the result of gets and perform the regex check against this value explicitly.

I'm not aware of any use case for performing this check with an empty regex, especially when defined as a literal value. The result you've highlighted would indeed catch most ruby developers off-guard.

Answer 2

This isn’t a bug. What is happening is Ruby is rewriting the code so that

if /foo/
  whatever
end

effectively becomes

if /foo/ =~ $_
  whatever
end

If you are running this code in a normal script (and not using the -e option) then you should see a warning:

warning: regex literal in condition

This is probably somewhat confusing most of the time, which is why the warning is given, but can be useful for one lines using the -e option. For example you can print all lines matching a given regexp from a file with

$ ruby -ne 'print if /foo/' filename

(The default argument for print is $_ as well.)