Should %WrapForValidIteratorPrototype% define a Symbol.toStringTag?

I have questions Spec Reading
1

I noticed most prototypes used with Generators/Iterators define toStringTags:

  • Iterator prototype: "Iterator"
  • Generator prototype: "Generator"
  • GeneratorFunction prototype: "GeneratorFunction"
  • Iterator helper prototype: "Iterator Helper"

One that does not is %WrapForValidIteratorPrototype%. It wouldn't have stuck out except for the fact that the iterator helper prototype (%IteratorHelperPrototype%) defines a toStringTag and the iterator wrapper effectively plays the same role, defining next/return for instances created by methods the Iterator interface.

const wrapperInstance = Iterator.from({})
const wrapperInstanceProto = Object.getPrototypeOf(wrapperInstance)
console.log(Reflect.ownKeys(wrapperInstanceProto)) // ['next', 'return']
console.log(wrapperInstanceProto[Symbol.toStringTag]) // "Iterator" (inherited)

const helperInstance = [].keys().drop(0)
const helperInstanceProto = Object.getPrototypeOf(helperInstance)
console.log(Reflect.ownKeys(helperInstanceProto)) // ['next', 'return', Symbol(Symbol.toStringTag)]
console.log(helperInstanceProto[Symbol.toStringTag]) // "Iterator Helper" (own)

Should %WrapForValidIteratorPrototype% have its own toStringTag to be consistent with %IteratorHelperPrototype%?

2

Good spot!

The Iterator subclass used in Iterator.from inheriting a string tag of "Iterator" feels like the right name to me. As you can't new Iterator, this subclass is essentially as close as you can get to a plain Iterator.

3

Is there a reason why "Iterator Helper" exists? That could also have inherited "Iterator".

4

The .next and .return methods for iterator helpers needs somewhere to live, and it can't be the base Iterator class, because it doesn't have anything to do with user-defined iterators.

(Or do you just mean the name? I think we generally give different names to different things, but you're right that it's not really necessary. TBH I don't think anyone thought about it all that hard. It's mostly a diagnostic.)

5

Yes, this is about the tag, not where next/return lives. Both objects define next/return sitting between an iterator object and Iterator but only one defines the tag ("Iterator Helper"). Its this inconsistency that prompted me to ask.

6

If it really is mostly diagnostic tho, I'm not sure the inconsistency matters enough to fix. Like has anyone actually hit a case where they needed to check the toStringTag on one of these and got burned by the difference? Or is this more of a "the spec should be internally consistent" thing

7

Both. Debugging tools need to be able to describe every value in a maximally useful way, and Symbol.toStringTag helps with that.