Add zero? to Number, Time::Span, and Complex

[danini-the-panini]

No description provided.

[refi64]

But...why? x.zero? is even a character longer than x == 0, so I'm not seeing any real benefit...

[0x1eef]

@kirbyfan64 it's a Rubyism.

[bcardiff]

The only benefit I see in ruby is to use it in a map / filter. But in crystal it is possible to do

[1,0].map &.==(0) # => [false, true]

[ysbaddaden]

Not as pretty as ary.reject(&.zero?) but more flexible since it can take any value.

[danini-the-panini]

I think it's more "human readable"

e.g.
do_the_thing until value.zero?

as opposed to
do_the_thing until value == 0

I ran into it while converting some Ruby code into Crystal so I thought I'd add it. It also might save some Rubyists from a few surprises as well.

EDIT I agree with @ysbaddaden. IMO it's prettier to write ary.reject(&.zero?) than ary.reject &.==(0). It also "reads" more like English.

[makenowjust]

@jellymann There is Crystal land, so you need to learn Crystal culture.

And, I don't think zero? is bad idea when I call Number.zero and another T.zero to mind (T is a class having zero class method). The predicate to check equality with T.zero should be named zero?, and it can't simply replace x == 0 (Of course, we can replace it as x == typeof(x).zero). In fact Time::Span has zero class method and its instance can't compare with 0. You should approach it with Time::Span#zero?.

[Sija]

why not simply @ticks == 0?

[danini-the-panini]

Read @makenowjust's comment. This is a more general approach, comparing directly to the type's definition of "zero"

[Sija]

This "more general approach" needlessly allocates new object on the stack, while actually you only need to compare the @ticks ivar here. There's a reasoning behind it in relation to Number since it may hold different values not always comparable with 0 — as Int32. It does not apply here at all though.

[RX14]

If it's a general implementation, then it should be on a more general type.

[Sija]

I don't see how Time::Span is a general type. There's Time::Span::Zero constant more suitable for this anyhow.

[RX14]

@Sija I was agreeing with you.

self == typeof(self).zero is a general implementation because it works on all types with a self.zero implementation. I was saying that there's no point in using a more general implementation like this versus @ticks == 0, unless you move #zero? to Object.

[danini-the-panini]

Okay, so there's no point in doing self == typeof(self).zero if it's not on a general type. Number is a general type, so it's probably okay to leave it. Time::Span and Complex could probably be more specific, though, since they're concrete types.

[danini-the-panini]

Unless we create a Zeroable module that we just include on every type that has a self.zero implementation? That also allows people to juste drop in Zeroable on their own classes if they need to.

e.g.

class Vector3
  def self.zero
    new 0, 0, 0
  end
  include Zeroable
end

[RX14]

That could work, although it seems a bit verbose to have a module just for that.

[Sija]

why not simply self.to_f == 0?

[danini-the-panini]

Read @makenowjust's comment. This is a more general approach, comparing directly to the type's definition of "zero"

[bcardiff]

For struct Number is ok the typeof(self).zero since the literal expanded would be of exact type and that is better. But on Complex and Timespan I would say to go for the plain/@ivar == approach. The compiler will end up inlining and simplifying it, but I think is simpler the @ivar == and we avoid the extra work in the optimization.

[danini-the-panini]

@kirbyfan64 Is Crystal's goal to save keystrokes?

You’d think that a language inspired by Ruby would actively embrace Rubyisms.

[ysbaddaden]

We don't want to copy every rubyism. For example we avoid aliases and prefer a single way or method to do something. To add a new feature into the core/stdlib we need to make sure it has a real, added, value.

[JacobUb]

One benefit of this would be slightly more type safety because in x == 0, "x" could, by mistake, be of some type with no meaningful comparison to a number and x.zero? would throw a compiler error instead.

[bcardiff]

Since using #zero? is funner and I see no cons on adding this I am open to include it.

Yet, if an implementation is supposed to receive a number (scalar or complex), checking with == 0 is enough. Even if typeof(0) != typeof(number). So the only value of adding this is to have some unified way to distinguish numbers and timespans zeros. If anyone can highlight a benefit for this it might help on others to 👍 or 👎 .

[danini-the-panini]

I'd just like to say, another reason why I think this is a good fit is that Int already has even? and odd?, and I think zero? fits well into that group of functions.

Also, Complex#zero? is easier than x.real == 0 && x.imag == 0, and more concise than x == Complex.zero. Similarly for time spans, consider x.ticks == 0 or x == Time::Span.zero vs x.zero?. I think it's pretty good reason for zero? to exist, and in going with POLA, Number ought to have it as well.

[ozra]

I also think zero? makes sense (as an "almost anti ruby" dude at that). Zero is not "just another number". And as already mentioned, in generic code one call covers a bunch of ugly situations. I've used the corresponding thing in C++ for generic containers/readers etc. [ed: for some rather specialized datatypes where 0 still "is a thing"] and I imagine I'll stumble in those directions in Crystal too. +1.

[bew]

Bump, what's the state of this PR? (the build error is about file formatting)

[akzhan]

I vote for this pull request.

Zero has special meaning, and need zero? just like infinity? and nan?.

Formatting should be updated due to changes in crystal formatter itself.

[bcardiff]

@jellymann are you available to fix the formatting so this can be merged?

[danini-the-panini]

@bcardiff I've fixed the formatting issues, but the Travis build is still failing for some reason.

[Sija]

@bcardiff C'mon, lets merge #4528...

[bcardiff]

Thanks @jellymann!