tc39 / proposal-Math.signbit

Math.signbit
9 stars 6 forks source link

Petition to use `Number` namespace instead of `Math` #7

Open Rudxain opened 2 years ago

Rudxain commented 2 years ago

Why?

One problem is handling non-numeric inputs, because it can't rely on coercion, so I suggest throwing an error, returning undefined instead of a bool, or switch to returning Numbers and return NaN

ljharb commented 2 years ago

Number works with Numbers. It wouldn't make sense for something on Number to work with BigInt, or a future Decimal.

I would find it exceeding surprising if something on Number worked with BigInts.

Rudxain commented 2 years ago

Number works with Numbers. It wouldn't make sense for something on Number to work with BigInt, or a future Decimal.

At no point I mentioned BigInts, that is completely unrelated to what I said. However, it is related to this proposal, specially if this other proposal gets approved.

But signbit is supposed/intended to be used with floats, because anyone can do someBigint < 0n to get the sign bit, floats are more complicated to work with, so there's no need to make signbit support BigInts. BigDecimals and BigFloats on the other hand, depend on implementation, some libraries don't have NaN or Infinity at all, and having a negative zero in modern day would probably be considered a bug instead of a feature.

I may be wrong, but I don't see any reason to future-proof this proposal by sacrificing present-day consistency

hax commented 2 years ago

Sounds reasonable. Consider sign bit as the implementation details also help to explain the sign bit of ±NaN problem (#1) .

Future Decimal could have their own Decimal.signbit if needed, just like they may need Decimal.NaN.

Another thought is, maybe it should be Number.prototype.signbit or just Number.prototype.sign.

Prior Art: Swift hasFloatingPoint.sign instance property work like signbit. BTW, I also feel swift's floating api have some interesting things like significand/exponent/nextUp/nextDown etc. which are useful when dealing with floats and maybe worth to add to JS in the future.

About handling input which type is not number, I prefer throwing, especially if it is a prototype method.