Will adding user properties to arrays break existing code, like recursive serialization/deserialization or object transformation?

[justingrant]

If this propoosal is added to the language, it'd make it more ergonomic to add properties to arrays. But adding properties to arrays will likely break a lot of existing code that assumes that arrays are mutually exclusive from plain objects. So I'm not sure that we want to make it more ergonomic!

For example, JS code for object serialization/deserialization or recursive transformation of objects typically assumes that arrays don't have userland-added properties. Here's just one example that I pulled from one of my projects:

/** Recursively sort keys in an object */
function sortKeys(obj) {
  if (Array.isArray(obj)) {
    return obj.map(sortKeys);
  } else if (obj && typeof obj === 'object') {
    return Object.keys(obj)
      .sort()
      .reduce((sorted, key) => {
        sorted[key] = sortKeys(obj[key]);
        return sorted;
      }, {});
  }
  return obj;
}

A more comprehensive example is here, from MongoDB's BSON library that is responsible for serializing data to/from MongoDB.

[mhofman]

it'd make it more ergonomic to add properties to arrays

Why do you think this proposal would make it more ergonomic?

Our use case is actually to make it cheaper to detect when code does this to disallow such values.

[senocular]

Arrays are just objects and can have named properties arbitrarily added to them just like any other ordinary object. The language itself takes advantage of this.

const result = "a".match(/a/)
console.log(Array.isArray(result)) // true
console.log(Object.hasOwn(result, "input")) // true
console.log(result.input) // "a"

Others also take advantage of this. The TypeScript compiler, for example, has a NodeArray type which is an Array with extra properties.

https://github.com/microsoft/TypeScript/blob/cc2610fd347127c28609b4fca6fa9d55ee5063c6/src/compiler/types.ts#L1584-L1592

Such properties should not be expected to survive normal serialization, however, since properties like these are not supported in the array literal syntax ([...]).

[ljharb]

I'm not sure it would make it any more ergonomic - it'd make it easier to reject array with properties, though.

[justingrant]

Sorry for being late to reply, I've been a at a conference.

it'd make it more ergonomic to add properties to arrays

Why do you think this proposal would make it more ergonomic?

I was mostly responding to the code sample in the readme. A built-in function is more ergonomic than this:

Object.keys(arr) // Enumerable properties only
  .filter(key => !(/^0|([1-9]\d*)$/.test(key) && +key < 2 ** 32 - 1));

More generally, the presence of a built-in API can be a hint to programmers that a pattern is a good idea to use.

Our use case is actually to make it cheaper to detect when code does this to disallow such values.

That is a good use case! It'd be good to clarify this in the readme.

it'd make it easier to reject array with properties

If that's the primary use case, then should the API be Array.hasNonIndexProperties? This would seem to address your valid use case without providing moral hazard that encourages users to start adding properties to arrays which would make them unserializable and/or untransformable.

[ljharb]

String.prototype.isWellFormed isn't a hint that non-well-formed strings are a good idea to use; I don't think this proposal would hint that expando properties on arrays are a good thing (at least, not more than the language itself producing arrays like that in multiple cases)

[justingrant]

String.prototype.isWellFormed isn't a hint that non-well-formed strings

I agree. A binary-returning function like this seems like a good way for developers to detect problematic data, and it doesn't make it easier to use non-well-formed strings.

However, this proposal would make it more ergonomic to extract expando properties from arrays, which goes beyond what's necessary for simple detection of problematic expandos.

Why not just have a Array.hasNonIndexProperties binary-returning API like we have with well-formed strings?

[ljharb]

Because logging is a primary use case, and that requires getting the actual string names.

Note that it's already ergonomic to grab all those property names - it's just not performant for large arrays.