Shouldn't .take() return IterableIterator instead of Iterator

[FrameMuse]

The README.md mentions that abstract naturals().take() returns Iterator

function* naturals() {
  let i = 0;
  while (true) {
    yield i;
    i += 1;
  }
}

const result = naturals()
  .take(3);
result.next(); //  {value: 0, done: false};
result.next(); //  {value: 1, done: false};
result.next(); //  {value: 2, done: false};
result.next(); //  {value: undefined, done: true};

I'm curious why an iterator that already knows the number of iterations still returns Iterator and not IterableIterator, as in Set.keys(). Additionally, I believe it would be more obvious to cast reduce on IterableIterator instead of Iterator.

Although using array methods such as reduce on IterableIterator would mean implementing reduce (and probably others) there instead, I still think it's a better solution than recreating the same features for each new proposal.

What are your thoughts?

[Josh-Cena]

An Iterator in JS is an IterableIterator, because Iterator instances implement @@iterator. See microsoft/TypeScript#54481 and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator#proper_iterators

[ljharb]

What is Set.items()?

[FrameMuse]

An Iterator in JS is an IterableIterator, because Iterator instances implement @@iterator. See microsoft/TypeScript#54481 and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator#proper_iterators

Then TypeScript kinda sucks here, right? (at least right now)

[Josh-Cena]

That's right—which is what the issue discusses. The only non-breaking fix will be to separate Iterator as a value from its meaning as a type.