js-choi

The extensions system and the bind-this operator

There are two proposals that do similar things.

• A [proposal for an Extensions system][Extensions system]: ::{ extFn } = obj, obj::extFn, and obj::extNamespace:extFn.
• A [proposal for a bind-this operator][bind-this]: obj->fn and obj->(fn).

js-choi

BigInt Math research (2021)

The problem: Math.sign, Math.abs, Math.pow, Math.min, and Math.max currently only accept Numbers; there is no similar functionality for BigInts.

See the main proposal repository.

Yaffle has also made a forum poll about some of these questions.

Should BigInt sign/abs/pow live in the Math object or in the BigInt object?

The first option: Math.sign, Math.abs, and Math.pow are extended to also accept BigInts.

js-choi

177726827	debug-4.1.1.tgz/src/common.js:111:			createDebug.formatArgs.call(self, args);
177726827	debug-4.1.1.tgz/src/common.js:101:					match = formatter.call(self, val);
154772106	kind-of-6.0.2.tgz/index.js:54:  type = toString.call(val);
139612972	readable-stream-3.4.0.tgz/lib/internal/streams/end-of-stream.js:68:      return callback.call(stream, err);
139612972	readable-stream-3.4.0.tgz/lib/internal/streams/end-of-stream.js:63:      return callback.call(stream, err);
139612972	readable-stream-3.4.0.tgz/lib/internal/streams/end-of-stream.js:55:    callback.call(stream, err);
139612972	readable-stream-3.4.0.tgz/lib/internal/streams/end-of-stream.js:51:    if (!writable) callback.call(stream);
139612972	readable-stream-3.4.0.tgz/lib/internal/streams/end-of-stream.js:43:    if (!readable) callback.call(stream);
139612972	readable-stream-3.4.0.tgz/lib/internal/streams/buffer_list.js:16:  Buffer.prototype.copy.call(src, target, offset);
139612972	readable-stream-3.4.0.tgz/lib/_stream_writable.js:248:  Stream.c

js-choi

This proposal introduces Object.equiv, Object.diff, and Symbol.diff.

Object.equiv would essentially be:

function equiv (objectA, objectB) {
  for (const d of Object.diff(objectA, objectB)) {
    return false;
  }

js-choi

I think @bakkot gives some persuasive points, especially that the mapping function is actually essentially an async function, so it wouldn’t make sense for its identity to be x => x.

My priorities, in order, have always been:

1. Array.fromAsync(i) must be equivalent to Array.fromAsync(i, undefined) and Array.fromAsync(i, null). (For optional parameters, nullish arguments should be functionally equivalent to omitting the arguments. This is how every function in the core language is designed, and I believe it is also an explicit best practice in Web APIs.)

2. Array.fromAsync(i) must be equivalent to for await (const v of i). (The default case of fromAsync must match intuitions about for await (of), just like how from matches intuitions about for (of).)

3. Array.fromAsync(i) should be equivalent to AsyncIterator.from(i).toArray().