Expand R&T support across methods that accept objects and arrays

[nicolo-ribaudo]

I didn't add support for:

• Reflect.*, since they already disallow primitives even if it would make sense to use them (e.g. Reflect.get("str", 0)).
• Proxy handler (new Proxy(target, #{})), since it's meant to contain functions so a record would only work as an empty handler.
• JSON.stringify's replacer array, just to avoid conflicts with Update boxes to work in SES environments #257: I'll do it in a separate PR in the future EDIT: done. There are also a bunch of bugs in the current JSON implementation, where we pass R/T to AOs that expects objects.

Closes #107

This PR should be reviewed commit-by-commit. Most algorithms in the misc-updates.html file are copied from the existing spec (except for InitializeTypedArrayFromTuple and UnwrapIteratorResult): focus on the <ins> and <del> tags.

[nicolo-ribaudo]

Do you think that these should be valid?

new Map([ #{ 0: "x", 1: "y", length: 2 } ]);
new Map([ #{ 0: "x", 1: "y", length: 1 } ]);
fn.apply(thisArg, #{ 0: "x", 1: "y", length: 2 });

[mhofman]

Do you think that these should be valid?

new Map([ #{ 0: "x", 1: "y", length: 2 } ]);
new Map([ #{ 0: "x", 1: "y", length: 1 } ]);
fn.apply(thisArg, #{ 0: "x", 1: "y", length: 2 });

AddEntriesFromIterable doesn't currently require a length so I'm not sure a check should be added now.

Since we're adding support for tuple, and these already support array like objects, why not add array like records support as well?

[ljharb]

Most places only accept an arraylike, or only an iterable; Array.from is one of the only ones that accepts both. new Map only accepts an iterable - being arraylike is irrelevant. Map and Set should not accept Records, since they're not iterables.

[mhofman]

AddEntriesFromIterable only cares about the entries of the iterable being an object with a 0 and 1 property.

d. If Type(nextItem) is not Object, then
  i. Let error be ThrowCompletion(a newly created TypeError object).
  ii. Return ? IteratorClose(iteratorRecord, error).
e. Let k be Get(nextItem, "0").
f. IfAbruptCloseIterator(k, iteratorRecord).
g. Let v be Get(nextItem, "1").
h. IfAbruptCloseIterator(v, iteratorRecord).

[ljharb]

I stopped partway through, but overall it seems like it'd be better to avoid the frequent object coercion if possible

[ljharb]

wouldn't this just work the same without the object conversion? ie "if it's not tuple or object", and then later, the Get will Just Work?

[nicolo-ribaudo]

Get expects an object: https://tc39.es/ecma262/#sec-get-o-p

The alternatives are:

• Special-case records and tuples in Get (I cannot use _record_.[[Get]], since I think primitives don't have internal methods?)
• Use GetV, which is just ToObject+Get.

(same for LengthOfArrayLike)

[ljharb]

Special-casing Get and friends to handle records and tuples seems like a reasonable approach.

[nicolo-ribaudo]

Looking at the whole spec, Get() is used ~140 times on objects. We would need to call it on tuples only ~10 times, so I think it's better to use GetV when dealing with "R&T or objects", making it easier to see "this will only be called with objects, thus we can make these assumptions/optimizations" in the majority of cases while reading the spec.

[ljharb]

What about future edits? It seems like it'd be an easy mistake to make to use Get with an R&T and have it break.

[nicolo-ribaudo]

It would be as hard/easy as it is to currently accidentally use primitive strings where we expect array-like values. When we are not sure that we have an object, we should use GetV "by defaut" in any algorithm.

[ljharb]

i'm not sure i see that - records are object-like and tuples are array-like, conceptually, and strings being actually arraylike doesn't mean they're conceptually arraylike :-)

[ljharb]

@mhofman ah, i see what you mean. yes, that's true, it seems reasonable for either Tuples or Records to be the entry objects in Map/Set/Object.fromEntries.

[acutmore]

For reviewers: isconcatspreadable not deleted but moved to miscellaneous-updates.html

[michaelficarra]

I don't think IsConcatSpreadable should treat tuples as arrays. IsConcatSpreadable is a hook for things that are much more array-like, such as NodeLists in HTML.

[Jack-Works]

IsConcatSpreadable is a hook for things that are much more array-like

Isn't tuple array-like?

[ljharb]

It is 100% arraylike; i fail to see why it wouldn’t qualify.

[acutmore]

I don't think IsConcatSpreadable should treat tuples as arrays. IsConcatSpreadable is a hook for things that are much more array-like, such as NodeLists in HTML.

Hi @michaelficarra , would you be able to expand on this? What would your expectation be for the following:

let a =  ['a1', 'a2'];
let b = #['b1', 'b2'];

a.concat(a); // ['a1', 'a2', 'a1', 'a2'];
a.concat(b); // ?
b.concat(a); // ?
b.concat(b); // ?

[michaelficarra]

It is 100% arraylike; i fail to see why it wouldn’t qualify.

Yes array-like in that it has a numeric length and numeric indices, but not meeting the bar for concat. Notice that general array-likes like { length: 0 } and arguments objects do not get spread by concat.

What would your expectation be for the following:

let a =  ['a1', 'a2'];
let b = #['b1', 'b2'];

a.concat(a); // ['a1', 'a2', 'a1', 'a2']
a.concat(b); // ['a1', 'a2', #['b1', 'b2']]
b.concat(a); // whatever you like
b.concat(b); // #['b1', 'b2', 'b1', 'b2'];

[ljharb]

I agree that concat doesn’t spread all arraylikes - but Tuple is far closer to an array than most arraylikes, as a conceptual and iterable List, with list operations on its prototype.

[michaelficarra]

I agree that concat doesn’t spread all arraylikes

This is far too weak of a statement. It spreads no array-likes. It is meant to only spread arrays. For historical HTML integration reasons, we had to add the isConcatSpreadable hook, but concat spreading should never be expanded further.

[ljharb]

Yes, it only spreads Arrays and NodeLists, but Tuples are also built-in list-like collections. Why wouldn’t we want to expand it further? Array concat’s flattening behavior is immensely idiomatic and useful.

[michaelficarra]

Array concat’s flattening behavior is immensely idiomatic and useful.

I'd argue that concat spreading is more-often-than-not a footgun. This is why the usage pattern of a.concat([b]) came to be: fear that b may be spread.

[ljharb]

That’s also why a.concat(b) is so common - the hope that if a list, it will be spread, and if not, not. Because spreading syntax also spreads strings, prior to flat existing, concat was the only way to do this, and as such it’s quite common to do so.

[acutmore]

There are other places where we are treating Tuples more like Arrays than 'array-like'. Namely Array.prototype.flat and JSON.stringify. A general design philosophy of Tuples is to think of them like Arrays, rather than Array likes, this can be seen in their literal syntax sharing the [ ] style and Tuple.prototype being a subset of Array.prototype.

[ljharb]

Additionally, Tuple has concat, which uses IsConcatSpreadable. #[a].concat(#[b]) is and must be #[a, b], and thus, [a].concat([#b]) must be [a, b] for consistency (and because that's the only thing that makes sense).

[michaelficarra]

@ljharb Nothing requires Tuple's concat to use IsConcatSpreadable.

[ljharb]

I think user expectations do. We added a bunch of methods to Array just so Arrays and Tuples would be consistent. If arrays can spread Arrays and NodeLists, Tuples must be able to as well, but the same logic.

[bakkot]

If arrays can spread Arrays and NodeLists, Tuples must be able to as well, but the same logic.

Ehhh.... NodeLists contain non-primitives pretty much by definition. I am entirely OK with Tuple.prototype.concat rejecting empty NodeLists in addition to non-empty NodeLists (which it must anyway).