Issue #9123 has been updated by alexeymuranov (Alexey Muranov).


=begin
--- avit (Andrew Vit) wrote:
--- > Also, why should we return nil in any case? I think the correct return value should be false, not nil. (nil implies an unknown or unavailable answer, but we *do* know if the number is 0 or not.) In other words:
--- > 
--- >     42.nonzero? #=> 42
--- >     0.nonzero?  #=> false

I think, if (({0.nonzero?})) is (({false})), then (({42.nonzero?})) should be (({true})).

Slightly off topic, but how about something general like

  class Object
    def non(*args)
      self unless args.include? self
    end
  end
=end
----------------------------------------
Feature #9123: Make Numeric#nonzero? behavior consistent with Numeric#zero?
https://bugs.ruby-lang.org/issues/9123#change-43093

Author: sferik (Erik Michaels-Ober)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


Numeric#zero? returns true or false, while Numeric#nonzero? returns self or nil.

I've written a patch that fixes this inconsistency and adds a Numeric#nonzero (non-predicate) method that returns self or nil for chaining comparisons. I'd like for this to be included in Ruby 2.1.0.

https://github.com/ruby/ruby/pull/452.patch


-- 
http://bugs.ruby-lang.org/