Editorial: consistency around List iteration

[bakkot]

Every place that an algorithm talks about iterating a List it now says 1. For each element _name_ of _list_, do, rather than saying "in" or "that is a member of" or "from" or whatever. Sometimes an actual type is used in place of "element".

I also added a sentence to the description of the List type that explicitly says Lists are iterated in order, and removed the few places in the spec text which explicitly specified that the order of iteration was the order of the List. (Most places just assume it.)

Marked as a draft until I get feedback on this and, if we are in favor of these changes, add a lint rule to ecmarkup to enforce this style where possible. Edit: ready to go. The first commit bumps ecmarkup, which fails linting, and the second commit changes the list iteration style and then passes linting. They should be landed in reverse order.

See also #2142.

[jmdyck]

Was there ever the idea that, if a "For each" didn't state an explicit order, then the order didn't matter (i.e., either the order made no observable difference, or it did but the different behaviors were all deemed valid)? Looking at past editions, I don't think so, but it's hard to be sure.

In cases where different iteration orders would result in different behaviors, does test262 require "List order"?

[michaelficarra]

Suggested change

	1. For each Record { [[Key]], [[Value]] } _p_ of _importMetaValues_, do
	1. For each Record _p_ of _importMetaValues_, do

I don't think mentioning the fields adds anything here.

[bakkot]

Since these are anonymous Records, the fields are essentially part of the type. I'd lightly prefer to keep them.

[ljharb]

could we make them proper named records instead?

[bakkot]

We could, but this and the host-defined AO which provides this list are the only two places which talk about this particular kind of record, so I think adding another layer of indirection there would hurt rather than help clarity.

[michaelficarra]

Same here.

Suggested change

	1. For each Record { [[WeakRefTarget]], [[HeldValue]], [[UnregisterToken]] } _cell_ of _finalizationRegistry_.[[Cells]], do
	1. For each Record _cell_ of _finalizationRegistry_.[[Cells]], do

[michaelficarra]

LGTM. You should also look into instances of iteration that empty the list, such as this one: #2122 (review). We can normalise those and probably convert many of them to this form if they don't use the list afterward. There's also some that do indexing manually that we could probably convert.

[bakkot]

You should also look into instances of iteration that empty the list

Good catch, will do.

There's also some that do indexing manually that we could probably convert.

Yes:

• in RegExpBuiltinExec step 27, for the captures list discussed in Editorial: Add notes about the 1-based indexing of regular expression _captures_ #2150, which I don't want to touch until we've sorted that out
• in step 15 of CreateDynamicFunction
• in String.fromCharCode
• in String.fromCodePoint

I'll address the latter three.

[michaelficarra]

Be careful, the CreateDynamicFunction one doesn't cover the whole list.

[bakkot]

@michaelficarra I added a pair of commits converting those two styles of iteration into the standard style.

There's still an instance of the first style in ForInIteratorPrototype.next step 7.b, but that one is relying on the list mutation to persist state across invocations, so it shouldn't change.

I also left CreateDynamicFunction alone, so the only instances of the second style I changed were in String.fromCharCode and String.fromCodePoint.