Make all numeric coercions explicit.

[paulp]

Optimistically, this is preparation for a day when we don't let numeric types
drift with the winds. Even without the optimism it's a good idea. I found a
couple bugs in the process - how many people would see this one coming without
compiler help. One of these methods has an inappropriately wide return type.

def signum(x: Int): Int = java.lang.Integer.signum(x)
def signum(x: Long): Long = java.lang.Long.signum(x)
def signum(x: Float): Float = java.lang.Math.signum(x)
def signum(x: Double): Double = java.lang.Math.signum(x)

Managing type coercions manually is a bit tedious, no doubt, but it's not
tedious enough to warrant abandoning type safety just because java did it.

[soc]

I agree in general, but the signum case is a pretty bad example. I have been working on related pieces of code and the huge issue is that we either need to decide

• on one return type for signum, regardless of the input number type¹
• on a return type which equals the input type

¹ Have a look at https://github.com/scala/scala/blob/master/src/library/scala/math/Numeric.scala#L205 where this goes terribly wrong, affecting all numeric types.

Even if it might create a minor performance hit to convert an Int to a Long the gained consistency is worth it, imho.

[soc]

And when I said "terribly wrong" I don't meant "the numeric type drifts and it's annoying", but "we convert NaNs back to valid numbers"!

Compare Double.NaN.signum to math.signum(Double.NaN)

[paulp]

If it was intentional, it couldn't have been gone about in a worse way. If you want to bring consistency to something, bring some consistency and document what you did. Keeping the same name, the same overloads, and making an almost invisible change to the return type of one alternative -- and then not documenting that anything has changed from what is being forwarded -- is a better example of how to propagate inconsistency than how to limit it.

[soc]

I totally agree. I think a comment should be added to explain why it is done.

[retronym]

The overall patch LGTM, but I haven't followed the signum discussion closely enough to know if this patch is good to merge or not.

[paulp]

I don't have any feelings about signum, so I'll put it back as it was and comment that it's intentional.

[soc]

LGTM