TC39 General
2021-08-13
plaintext logs
prev next
source on github
11:01
<devsnek>
I don't remember why I removed extending null from the March agenda but perhaps I can bring it to August.
13:58
<jschoi>
New proposal for extending Math methods to handle BigInts. https://github.com/js-choi/proposal-bigint-math, https://jschoi.org/21/es-bigint-math/
13:58
<jschoi>
Might present at next meeting for Stage 1. Stuck on a couple of questions.
14:00
<jschoi>
  1. Should round, floor, etc. take BigInts, acting as identity functions? Answer is currently no.
  2. Are there any real-use cases for hyperbolic/root/logarithm functions on BigInts? Answer is currently “don’t know” but they’re specified anyway.
  3. If we do extend hyperbolic/root/logarithm/irrational functions to accept BigInts, then should they return BigInts, and if so, how should they be rounded? Answer is currently yes and “it’s ‘implementation-approximated’”.
  4. Should trigonometric functions, which generally have small domains and ranges, return Numbers when given BigInts? Answer is no, and because of this we are not currently extending the trigonometric functions.
  5. What should the variadic Math.hypot, max, and min return when given no BigInt arguments? Answer: We make new big versions of each of them, and we make bigHypot return 0, and bigMax/bigMin throw a TypeError.
14:05
<jschoi>
ljharb: You mentioned a few months ago you were interested in such a proposal.
14:13
<bradleymeck>
Richard Gibson: yup, basically want a bunch of intrinsics methods that act like @@species is never anything except what the intrinsic they are directly on the prototype of
15:18
<ljharb>
@jschoi my answers are yes, don’t know, sounds good, probably reasonable, and I’d prefer not making new versions if possible
15:23
<jschoi>
Regarding the last question—What I’m concerned about is Math.max(0n, 1n) and Math.max() returning different types 1n and +Infinity, which might cause bugs if that type switching breaks programmer intuition with arrays of BigInts.
15:23
<jschoi>
Likewise with Math.hypot(...arrayOfBigIntsThatMightActuallyBeEmpty) returning +0 the Number instead of a BigInt whenever the array is empty.
15:25
<jschoi>
This probably would cause the same sort of implicit Number/BigInt type mixing that the original design was trying to avoid. Hence bigHypot and bigMax.
15:39
<ljharb>
I’m much more convinced by the second case than the first
15:40
<jschoi>
Yeah, basically the second case. It applies to all three variadic functions.
17:30
<Richard Gibson>

bradleymeck: so, this?

concat = function() {
  const receiverSpreadableValue = this[nativeIsConcatSpreadable];
  const isReceiverSpreadable = receiverSpreadableValue !== undefined ? !!receiverSpreadableValue : nativeIsArray(this);
  const substituteReceiver = isReceiverSpreadable ?
    { [nativeIsConcatSpreadable]: true, __proto__: this } :
    { [nativeIsConcatSpreadable]: true, length: 1, 0: this };
  return applyNativeConcat(substituteReceiver, arguments);
};
18:03
<bradleymeck>
Richard Gibson: yup but not slow XD that is the problem
18:04
<Richard Gibson>
quit moving the goalposts! 😝
18:13
<bradleymeck>
hah
22:13
<Richard Gibson>

I suspect it would be faster if it also deviated from Array.prototype.concat by ignoring the receiver, but I don't know if that works for your use case:

const noSpecies = { [nativeIsConcatSpreadable]: true, length: 0 };
concat = function(/*...items*/) { return appyNativeConcat(noSpecies, arguments); };