No consistency of enumerable in the next method

[jimmywarting]

I run some test from WPT on a polyfill of mine
And one of the test made sure that the next() method was enumerable.
My polyfill isn't exact 100% compatible but it's just good enough to get the job done...

I tough to my self... how come that it's not compliant to my generator function that i'm using...? it's not like I'm reinventing the hole Iterator class with next, throw, return methods... I'm using something like: class Polyfill { *values() {...} }

So i run some test agains on some built in classes that exist on the web/js and run this test

for (const Klass of [Headers, URLSearchParams, Array, Map, Set, Uint8Array]) {
  const iterator = new Klass().values()
  const prototype = Object.getPrototypeOf(iterator)
  const descriptor = Object.getOwnPropertyDescriptor(prototype, 'next')
  console.log(descriptor.enumerable)
}

function * foo() {}
const prototype = Object.getPrototypeOf(Object.getPrototypeOf(foo()))
const descriptor = Object.getOwnPropertyDescriptor(prototype, 'next')
console.log(descriptor.enumerable)

yields: (2) true, (5) false

How come that some next() methods are enumerable and some are not? it's so confusing and inconsistent. when should they be enumerable and when shouldn't they?
could this not please be normalized through out everything that is iterable to make life easier and more consistent?

[TimothyGu]

All Web IDL methods are enumerable (e.g., Headers.prototype.get), which is different from ECMAScript (e.g., Map.prototype.get). What you see in iterators is just an extension of this difference. It’s too late to change enumerability for all objects, so the most we could do is make it consistent within Web IDL.