Discuss
  • Traversal in insertion order for Set.prototype.add/delete

Traversal in insertion order for Set.prototype.add/delete

# Qantas 94 Heavy (11 years ago)

Maybe my brain's just fried, but is there any reason for Set.prototype.add and Set.prototype.delete enforcing iteration "by original insertion order"? There aren't any side effects that I know of by iterating through the list of elements in some other order, as all the elements of a set are meant to be unique. Am I missing something?

# Mark S. Miller (11 years ago)

We need a deterministic order. What deterministic order do you suggest? Why would it be better?

# Qantas 94 Heavy (11 years ago)

We need a deterministic order. What deterministic order do you suggest? Why would it be better?

Sorry for the confusion, I completely worded that wrong.

I'm specifically referring to the specification sections 23.2.3.1 and 23.2.3.4 (specifying the behaviour for Set#add and Set#delete), which states that:

  1. Repeat for each e that is an element of entries, *in original insertion

order*

I don't see any real reason why that's needed, unless there's some odd side effects of doing so that I'm not aware of. Sets are meant to be unique and I don't think the order of checking whether the element already exists really matters. I'm not advocating for any change for the deterministic order of iteration in Set#forEach and for-of loops on sets.

# Mark S. Miller (11 years ago)

I don't understand the issue. Could you give a tiny example test case for checking the specced order vs one for checking the order as you think it should be specced?

# Allen Wirfs-Brock (11 years ago)

You're right that phrase isn't need for probing operations such as used by add and delete. It only matters for iteration operations. In fact, that phrase doesn't appear in the corresponding methods of Map. I'll remove the unnecessary requirement.