Does it make a difference if something is defined in "Properties of X instances" or not?

Of all built-in objects, only Array#length, String#length, and RegExp#lastIndex are defined in the "Properties of X instances" section. Other instance properties are only implicitly specified through the implementation of the constructor, such as AggregateError#errors, Error#message (not Error.prototype.message), and Function#length. Error#cause is only conditionally defined so I can understand; but for others, do their absence from the "Properties of X instances" section have a normative impact?

No, I'm fairly sure that their absence from the "Properties of X instances" section is not normative. Though it might be nice to include them where they're missing to make finding them easier, and to make those sections more complete.

FWIW Error#message is also conditional:

Reflect.ownKeys(new Error).includes("message"); // false
Reflect.ownKeys(new Error("")).includes("message"); // true

and Function#length is also described outside of the constructor:

https://tc39.es/ecma262/multipage/fundamental-objects.html#sec-function-instances

20.2.4 Function Instances
Function instances have the following properties:
20.2.4.1 length

"Properties of X Instances" sections date back to ES1. They had a normative impact because the corresponding constructors weren't defined in much detail.

But ES6 (2015) defined the constructors with algorithms, being very specific about the internal methods, slots, and properties of the object being constructed. At that point, I think the "Properties of X Instances" sections became (mostly?) redundant from a normative point of view.

1 Like

Thanks! I missed the "Function Instances" section because it doesn't use the same title format... I wonder if it should be called "Properties of Function Instances".

At this stage I don't think there's anything else actionable, unless people think it would be nice to add message and cause to "Properties of Error Instances" with a note that they are optional.