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/