Kevin Gibbons

> The virtualization would be a combination of import-maps and JavaScript code, right? If early-running JS code cannot programmatically modify import-maps, then no, that would not be sufficient. Specifically: it...

@littledan Ah! I'd missed that, thank you. I believe that could be enough, yes, though I'd need to think more about it to be sure. (Part of the problem is...

> whereas `BigIntSqrt` and `BigIntCbrt` can then easily be implemented in userspace by the few who need them I continue to strongly disagree with this point of view. There are...

Would this allow passing the LHS multiple times, a la `x::y(?, ?)`? I'd expect it to, but in that case I'd also expect to be able to pass the LHS...

> Number.sum/BigInt.sum is far less weird than Math.sum/Math.bigSum How so? There's several other Math operations which will remain Number-only (`sin`, for example), and the "bigX" naming convention is already established...

> I think sadly that's somewhat an unavoidable consequence of the committee's decision to minimize the ability to mix Numbers and BigInts Well, no, it's completely avoidable: `Math.sum` could work...

I'd be fine with `Math.bigintSum` or `Math.sumBigInts` or something if that's the main concern. Or having `Math.sum()` and `BigInt.sum()`, for that matter. It's only really having `Math.sum()` which works on...

All major points _are_ resolved. All minor ones, too. That's what stage 3 means, and why stage 3 is specifically called out in the process document as the appropriate time...

@rdking > From this perspective, TC39 sees no need to further discuss the merit of their decisions with the community. Please don't speak for the committee. This is not true....

Often there are questions in design with fundamentally incompatible possible answers. "Should class fields use Set or Define semantics (or both or neither)" is one of them\*. Unless everyone agrees...