Regarding "Don't break user intuition"

[gweax]

The proposal states that "When a messy situation comes up, this proposal errs on the side of throwing an exception rather than silently giving a bad answer."

To me this is exactly the opposite of what my intuition says. The forgiving nature of JavaScript is to me an integral part of the language. Throwing an error seems so Java-ish. Especially when using the + operator. Although I understand the rationale behind it, I think the plus operator should never throw an error, because that's the way it currently is. Doing otherwise would break user intuition.

Axel Rauschmayer's proposal is in my opinion more consistant with regard to user intuition.

[bakkot]

The problem is, what type should e.g. 9007199254740993n + 0.1 be? (9007199254740993 is 2^53 + 1, for reference, which is not representable as a JS number.) Either choice looses precision.

That said, I'd maybe support implicit conversion to Integer when one operand is an Integer and the other is a number ≤ 2**53 with no decimal part (throwing when there is a decimal part). I'm not sure if this sort of conditional throwing is a good idea from an avoiding-bugs or implementation perspective, though.

(@rauschma's proposal looks like it changes the semantics of existing JS math, e.g. 2**53 + 1 === 2**53 would no longer hold, which I'm almost certain we can't do.)

[gweax]

I do understand the dilemma here. However, I'd rather lose precision than throw an error. Losing precision is something we already deal with IEEE 754, so it doesn't seem bad to me.

@rauschma's proposal is worth to be discussed, but this is not the place :-)

[bakkot]

However, I'd rather lose precision than throw an error.

In which direction, though? If there were a single obvious choice I'd agree, but I'm not convinced there is.

I think in cases where there's two highly conflicting intuitions for the semantics of some code, and it's possible to just make that code an error and instead require more explicit expressions of intent, it's better to make it an error. (For example, this is why -1**2 is a syntax error.)

[littledan]

@gweax If users are OK with losing precision, then they can stick with Number, and maybe pursuing this topic is a bad idea. But the idea here is that many users want to get greater precision, and this is a proposal towards that use case. Implicitly losing precision seems like the worst thing to do for these users, doesn't it?

[gweax]

Maybe this is a general issue of where JavaScript is heading to. It seems to me that currently steps are taken to change (or reduce) the nature of a loosely typed language. A part of that is implicitly coercing one type to another if the expected types don't match the actual ones.

Of course this lead to silly and sometimes inconsistent rules like "12" + 3 and "12" - 3, which is the source of much mockery of JavaScript. On the other hand, this fulfills the robustness principle (Postel's law) of "be liberal in what you accept from others".

Introducing a new data type that leads to runtime errors (in contrast to the syntax error of -1**2, which can be caught by linters) when used with an operator which until now did not throw an error (under no circumstances) feels like a bad idea. If this is a must towards a more sensible handling of loose types, then be it. I'd much more prefer a way that does not change the fundamental approach of JavaScript as I see it.

My reasoning lacks an alternative to how to cope with Integers and other types. This is because I'm not too much into the matter. If for the expected use case there is no other solution than to throw errors, well, then we have to go with it.

[bakkot]

used with an operator which until now did not throw an error (under no circumstances)

Pedantically:

Symbol() + 1; // throws
({ valueOf() { throw new Error('unsupported'); } }) + 1; // throws

So it's not a totally radical proposition, especially in es2015-land. Es2015 also tightens the type system in other ways, like making classes non-callable and generators non-constructible.

But it's true that this would be a step further in that direction, especially since Integers, unlike Symbols, do have a sensible interpretation when added to floats. (In fact they have two sensible interpretations, which conflict.) I think this is worth it: I think it will prevent far more bugs than it causes, without making it that much harder to write code.

[ljharb]

This would only prevent bugs when mathing numbers and "integers larger than 2**53" - how common do we think this is among users who know the difference and care about it?

[bakkot]

@ljharb, I can't tell what your "this" is referring to.

In any case, I suspect that most users of Integers will want accurate math when operating on Integers larger than 2**53 - otherwise they wouldn't use them.

[ljharb]

Right - I'm saying that very few users will be using integers that large and performing math ops with those integers and floats, and those rare users will be quite aware of the precision issues involved.

In other words, I'd be fine with only allowing integer conversion when it didn't drop precision; but lacking that, I think dropping precision is much better than throwing, since the extremely common case will not drop precision.

[gweax]

In fact they have two sensible interpretations, which conflict.

@bakkot This is also the case with other types and the plus operator. "12" + 3 has the sensible interpretation of "123" and 15. However, instead of throwing an error, it was chosen to prefer one interpretation over the other.

The more I think about it, the more I tend to say that Integer × <any other type> should convert the other type to an Integer.

Given, for example, an implementation of the Fibonacci numbers, a function written for "traditional" JavaScript could be something like that (with awful performance):

function fib(n) {
  if (n === 0 || n === 1) return n;
  return fib(n - 1) + fib(n - 2);
}

With Integer + Number converting the Number to an Integer, this function would work fine without any adaption. Not so with Integer + Number throwing an error (as at the end the Number 0 and 1 get added).

Existing code could benefit from implicit coercion, and this is a strong argument against throwing.

[kgryte]

The more I think about it, the more I tend to say that Integer × should convert the other type to an Integer.

@gweax What you propose is the exact opposite of what other environments do. For instance, in Python,

>>> x1 = int( 1 )
>>> type( x1 )
<type 'int'>
>>> x2 = 1.0
>>> type( x2 )
<type 'float'>
>>> x3 = x1 + x2
2.0
>>> type( x3 )
<type 'float'>

In Julia,

julia> x1 = 1;
1

julia> typeof( x1 );
Int64

julia> x2 = 1.0;
1.0

julia> typeof( x2 );
Float64

julia> x3 = x1 + x2;
2.0

julia> typeof( x3 );
Float64

The same type promotion rules apply to Java, C, and Perl.

Were JavaScript to pursue the path you proposed, porting numeric computing code would require considerably more work to ensure type conversions were handled in accordance with existing expectations.

The above, however, is not an argument against the possibility of implicit conversion, but were any conversion to occur the path would be from integer to double, not the other way around. For some operations, losing precision can be acceptable (e.g., + and -), but, for other operators, certain situations require throwing (e.g., domain errors of the variety integer(2)**(-integer(2))).

FWIW, in Julia,

julia> x = 9007199254740993
9007199254740993

julia> x + 1.0
9.007199254740992e15

[gweax]

This is very interesting for two reasons.

1. Porting implementations from other languages to JavaScript will likely be a major use case, when Integers are available. Pursuing the way of other languages therefore seems very reasonable.

2. As far as I understand this from your examples, these other languages don't throw, at least not for + and -. If JavaScript behaved differently, it would harm porting numeric code.

[littledan]

In C/C++, there are all these implicit casts in numeric operators and argument passing. However, they have been so error-prone in the past that many projects run with a compiler mode to reject programs which don't do explicit casts rather than depending on the implicit ones. I think many programs that people will be porting will already be uniform in this sense, and many of the ones that are not have bugs due to losing precision.

[mihailik]

Porting of C++/Java/Python code is cool, but it's 1000x more LOC of existing JavaScript that should be the priority.

Existing code should react to Integer inputs in predictable, smooth manner.

calculateCompoundReturn( 5n )

^^^^ If this works for 5, it should not crash for 5n. Otherwise you effectively designate Integer data type as a killer bomb to sink any existing complex code.

We have business logic, complicated rendering calculation, extensive well-tuned libraries like jQuery, d3, three.js and more. If integer throws, if it is a poisoned apple, maintainers of all those libraries will have a big trouble on their hands.