[ruby-core:93042] [Ruby trunk Feature#9123] Make Numeric#nonzero? behavior consistent with Numeric#zero?

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:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>