what's actually the rationale?

[michaelficarra]

In the README I see,

Array.getNonIndexStringProperties standardizes this common task

and

It is needed in all cases where correctness is important.

Why is this a common task? I've never needed to do this myself or seen code that does this. What's in the README right now doesn't seem sufficient.

[justingrant]

Even if this is a common task, do we want to encourage programmers to be adding userland properties to arrays? Seems like this pattern could be incompatible with a lot of existing code. See #2.

[ljharb]

Of course we don't want to - without this check, we can't reject those arrays in a performant fashion.

[lifaon74]

It feels like this proposal tries to fix an extremely rare edge case coming from a really bad practice.

The provided exemple should never append:

const a = [1, 2, 3];
a.description = "coords";
Object.defineProperty(a, "secret", {
  value: true,
  enumerable: false,
});
a[5] = 42;

Should be:

const a = {
  array: [1, 2, 3],
  description: 'coords',
  secret: true,
  // etc.
};

This is a far better alternative than extending the properties of an array. We may note that the provided example should never pass the code review. In consequence, I don't understand why this proposal would benefit to the JS ecosystem. Maybe I miss a point ?

[mhofman]

FYI we thought we needed this to detect extra properties on objects that aren't expected to have them. However after thinking it through, we don't actually need this. And can rely on other mechanisms.

[justingrant]

FWIW, my suggestion from #2 is to add a boolean-returning Array.hasNonIndexProperties instead, to make it more efficient to detect this bad pattern without making it easier to use that bad pattern.

[ljharb]

One of the primary use cases is logging, which requires getting the names.

[Slayer95]

FWIW, my suggestion from #2 is to add a boolean-returning Array.hasNonIndexProperties instead, to make it more efficient to detect this bad pattern without making it easier to use that bad pattern.

If the goal were to check that an Array is well-formed to some definition of well-formedness, it would also be interesting to ensure that it doesn't have holes. These checks could be coalesced into a single JSON.isValidArray() function, ensuring assert.deepEqual(foo, JSON.parse(JSON.stringify(foo)));, where foo is a shallow, maybe sparse, maybe expanded, array of well-behaved primitives (i..e no undefined, Symbol, function, which would have to be separately checked by consumers.)

Why is this a common task?
One of the primary use cases is logging, which requires getting the names.

I can see how this Array.getNonIndexStringProperties proposal can be useful and common in some libraries, but the README ought to be expanded with references to actual code it would replace.

On the other hand, most loggers rely on JSON, so JSON.isValidArray() could be a legit alternative.

[ljharb]

most loggers rely on JSON

I'm talking about the case where JS values are serialized to a string, which most loggers do not use JSON for, since JSON is incapable of documenting all JS values.

[Slayer95]

Actually, this would basically hold true, right?

function isValidJSONArray(arr) {
  if (!Array.isArray(arr)) return false;
  if (Object.keysLength(arr) !== arr.length) return false;
  return Array.getNonIndexStringProperties(arr).length === 0;
}

Then this proposal and Object.keysLength would become very nice building blocks.

I'm talking about the case where JS values are serialized to a string, since JSON is incapable of documenting all JS values.

This is of course true for arbitrary JS values, but in reasonably-controlled contexts, checking that an array can be correctly serialized to JSON, logging with JSON if so, and otherwise bailing out to ${arr.constructor.name} ${logElementsUsingGoodOldForIn(arr)} can be acceptable enough, with the advantage of handling holes out-of-the-box.

which most loggers do not use JSON for

This statement could use some references, if you intend to focus on the logging use-case.

[ljharb]

node's util.inspect, all test frameworks' output, and packages like object-inspect.