Arrays and TypedArrays use different definitions of indexed property name

[erights]

Unfortunately, Arrays and TypedArrays use different definitions of indexed property name. Yet another historical mistake that likely is too late to fix. Sigh.

Attn @gibson042

[ljharb]

The desired semantic here is actually that if it’s a typed array, it follows the typed array definition, otherwise the array/object definition. Do you think that’d be a problem?

[BridgeAR]

@erights thank you for bringing this up! That is actually an important aspect!

@ljharb that would indeed be the favorable behavior. I guess that is something to better clarify in the spec definition to get it to stage 2.7.

[erights]

It is at least unfortunate. I do not yet have an opinion on whether it portends deeper problems.

What about objects that are neither Arrays nor TypedArrays? I think the answer will likely determine if this creates a problem for practical membrane transparency via proxies.

[bakkot]

Personally, if we're doing "index" at all (which I am opposed to, in the absence of a very compelling use case), I would say it includes only 0 through 2^32 - 2, i.e. the array index properties. I can't really see a situation where someone has a 4GB+ TA and still cares about the result of this operation on that TA.

[BridgeAR]

The index case allow

• detecting sparse arrays early. This allows to have a fast path for dense arrays as well as faster and better handling for sparse arrays
• knowing if keys should be collected on an array to know about any additional key on an array which would be very expensive otherwise

The index cases exist in e.g., Node.js in util.ispect and util.isDeepStrictEqual. It is important that these APIs are fast to minimise any blocking CPU time.

[bakkot]

The index cases exist in e.g., Node.js in util.ispect and util.isDeepStrictEqual. It is important that these APIs are fast to minimise any blocking CPU time.

That something is useful in Node and/or in debug or test code is not generally a very compelling reason to add something to the language. To be worth adding to the language features should be useful to web applications.

[ljharb]

Presumably you mean at runtime, since browser dev tools would certainly make use of this?

[bakkot]

Yeah.

[BridgeAR]

We could move this to https://github.com/BridgeAR/array-get-non-index-string-properties. With the update to remove the index handling here, that would prevent any ambiguous index types.