ecma262
ecma262 copied to clipboard
tc39
Editorial: Replace terms "integer index" and "array index"
The problem with "integer index" and "array index" (defined in 6.1.7 The Object Type) is that they are terms for String values, and yet pretty much everything else in the spec (and a lot of usage outside the spec) assumes that an index is an integer value.
The term "integer index" is worse, because both words mislead the reader to think that this is an integer value. And there's a danger that someone can use the term in the natural sense of "an index that's an integer" without realizing that that conflicts with the given definition. In fact, this has happened in the current spec, where about half of the uses of "integer index" actually refer to an integer value: see step 14.c.i in String.prototype.split and the descriptions of all the [[FooNextIndex]] slots.
So I propose the following renaming:
- "integer index" -> "Uint53-string"
- "array index" -> "Uint32-string"
Rationale for the new terms:
- It's clear we're talking about a String value.
- But it's also fairly clear that they are related to unsigned integers, based on the "Uint32" terminology the spec already uses.
- And the "53" vs "32" makes explicit the distinction between two: the range of permissible values (which "integer" vs "array" doesn't really convey).
(Of course, I didn't convert the uses of "integer index" that weren't using it in the defined sense.)
The spec also used the terms "integer-indexed" and "array-indexed", but didn't define them or use them entirely consistently, so I added definitions for "Uint53-indexed" and "Uint32-indexed" and tried to be consistent in their usage.
(But I left "Integer-Indexed exotic objects".)
Effect on downstream specs:
-
"array index":
-
WebIDL uses "array index" in ES's sense, but defines its own abstract operation for "property name P is an array index", so it wouldn't have to change due to this PR. (It could if its editors wanted.)
-
HTML uses the term "array index property name", but refers to WebIDL's definition.
-
Intl doesn't use "array index".
-
-
"integer index":
-
Neither WebIDL nor HTML use "integer index".
-
Intl has 2 occurrences of "integer index", but not with this meaning, and not linking to ES.
-
These terms seem more precise, to be sure, but not more clear - why not “integer index String” vs “integer index Number”, etc?
The conclusion from the editor call is that Uint53-string and Uint32-string are not good names. While more clarity could be useful here, until better names are proposed, the churn here is not worth it.
That said, 90f7d8ffac106d8d5311cbfc93c1579531ea3d9d is independent of renaming and is useful in itself. @jmdyck would you like to make a new PR with that commit or morph this PR into just that commit?
While more clarity could be useful here, until better names are proposed, the churn here is not worth it.
Any guidance on your criteria for good names? (These still strike me as good names, so I'm not going to find better ones without a different metric for goodness.)
That said, 90f7d8f is independent of renaming and is useful in itself. @jmdyck would you like to make a new PR with that commit or morph this PR into just that commit?
Done (new PR).
@jmdyck Just to make sure we're all on the same page: editor group agrees that the existing labels aren't great, but we didn't like the suggestions here and we couldn't come up with any better ones, so this isn't going anywhere until someone comes up with names we like better. You're welcome to keep rebasing if you're inclined to; we just want to make sure you are aware of where the editors are at.
