Issue #9123 has been updated by shevegen (Robert A. Heiler). Quite a long old discussion. I checked before replying, to make sure I don't comment too often in one particular issue. So this is my first reply; and I will try to make comments that summarize my opinion. First, I would like to start that I do not think that this is a hugely important discussion either way. I understand that those who may wish to change the current behaviour feel different, but this is my personal opinion. :) So in some ways, I am like headius here in not having any really strong opinion. Now to the issue of .zero? first - I do sometimes use .zero? but quite rarely. For some reason I do not seem to need it. I do not remember a single case where I had to use .nonzero?. I think the name is not hugely elegant; it feels a bit clumsy. So in some ways I agree with those who would suggest e. g.: if !object.zero? In general I prefer "if" clause checking; I noticed that my brain needs more time when processing "unless" conditions. I also use "unless" just fine but it is not a clear winner to me per se, as opposed to "if !foo". But this is an aside. To the very situation itself - personally I think it would be more consistent to have .nonzero? just behave exactly like !object.zero? - I don't think people can expect for the "opposite" of a method that returns true or false, to either return self, or nil. This is from a consistency point of view - as was explained there was a history for the behaviour too. There is, I believe, no way for this to change in ruby 3.0. Perhaps past ruby 3.x this behaviour may be revisited, but again - I personally don't really care either way. To me it is not really important. This may be different for other folks, but since I don't use .nonzero? myself, and rarely use .zero?, it just does not affect me. So I guess this issue here is mostly about people who use .nonzero?. I am not sure how many use this, though - to me it seems as if only very few people use it; more people use @@foo variables in code, for example. I noticed this issue here due to this recent blog article: https://metaredux.com/posts/2019/06/11/weird-ruby-zeroing-in-on-a-couple-of-numeric-predicates.html The article also writes: > Most of the time you probably won¡Çt experience any issues related to that inconsistency, but > there are certainly cases where it is going to bite you. But since I don't really use these methods, they can not affect my own code now can they. ;) Bozhidar wrote: > Deprecations are not breaking anything, but advance the language forward. This depends on the change itself of course. Matz talked about it in a presentation e. g. good change, bad change. For example, if you can avoid a change. I understand both points, since it will always be a struggle of people who prefer change, as opposed to those who don't like a change (and they can not avoid it). The issue here is so minor, though - I think we need to put this into perspective too. If we look at past ruby 1.8.x, changes such as encoding, or the yaml change from syck to psych - these were larger changes. I have only recently switched to UTF-8 + psych finally (oddly enough due to emojis and unicode "building blocks" for commandline "interfaces" - this is actually more useful than plain ASCII, so that change was ultimately worth it; took me ~2 weeks or so of initial time investment). I disagree about adding a new method called non_zero that would return self or nil. To me this makes no sense. I also do not think that the method .nonzero? itself should be deprecated (and removed), but I am in favour of changing it to be consistent with .zero? in the long run, just as headius wrote back then. I think there is one important thing to note, though - while some folks here post about "purity" of a language, the ruby core team has stated several times before that real usage of ruby is a primary focus rather than abstract "perfect" design. Meaning - if there is a good specific use case then a change may be much easier than not having a good specific use case. I write this in general because I think this actually helps explain other changes in ruby where a good use case was given (see how the safe navigation operator was added). And all use cases have to be checked for side effects IF a change is made, too. Obviously I am biased too because I don't really depend on either #zero? or #nonzero?, but even this aside, I think this is such a small issue either way. ---------------------------------------- Feature #9123: Make Numeric#nonzero? behavior consistent with Numeric#zero? https://bugs.ruby-lang.org/issues/9123#change-78436 * Author: sferik (Erik Michaels-Ober) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * 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 -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>