Operator overloading breaks Asm.js

[ghost]

I'm not sure if it's a valid concern nowadays, but this proposal completely invalidates Asm.js syntax and type checking.

Consider this Asm.js function:

function xor(x, y) {
    x = x | 0;
    y = y | 0;
    return (x ^ y) | 0;
}

The | operator is used as a ToInt32 coercion, but if x, or y were objects that have | operator overloads introduced into scope, the function could not provably maintain the correct behavior of both JS and compiled code that would operate on integers.

A similar point was raised in the design of the BigInt proposal, should it hold here too?

[nicolo-ribaudo]

This proposal requires explicit opt-in: it would only invalidate asm.js type checking if you do something like this:

function xor(x, y) {
    with operators from MyOperators;

    x = x | 0;
    y = y | 0;
    return (x ^ y) | 0;
}

[ghost]

@nicolo-ribaudo Since the with operators statement is block scoped, is it possible to do the following:

new Vector([ 1, 2, 3 ]) + 3;

with operators from Vector;

While having the ... + 3 be the Vector defined + operator?

I presume the answer would be yes, but it may not be hoisted.

If it is hoisted, then this would result in invalid Asm.js:

function make_module() {
    "use asm";

    function xor(x, y) {
        x = x | 0;
        y = y | 0;

        return (x ^ y) | 0;
    }

    return {
        xor: xor
    };
}

with operators from MyOperators;

The engine couldn't know whether the code is valid unless it has parsed the entire file.

[ljharb]

Can’t it not know that anyways, in case there’s a parse error at the end?

[ghost]

Can’t it not know that anyways, in case there’s a parse error at the end?

Yes, there could be something such as a syntax error or a hoisted function used as a JavaScript import, so the file already has to be completely parsed, thus my point doesn't hold anyways.

This changes syntatical validation though, by breaking it in a new way. Is this a valid concern?