AsyncFromSyncIteratorPrototype.next calls syncIterator.next with a value when none is provided

[Jamesernator]

Something I noticed when implementing a small set of utilities (see here) for dealing with iterators I noticed that regardless of whether a value is actually passed or not to AsyncFromSyncIteratorPrototype.next one is passed forward to the syncIterator.next method regardless.

This is observable with the following code fragment:

const o = { 
    [Symbol.iterator]() {
        return this
    },
    next(...args) {
        console.log(JSON.stringify(args))
        return { done: true }
    }
}

async function test() {
    for await (const item of o) {}
}

test()
// Prints [null] in the d8 shell
// not sure where the null could come from in the spec

The synchronous version of the loop has no such value:

const o = { 
    [Symbol.iterator]() {
        return this
    },
    next(...args) {
        console.log(JSON.stringify(args))
        return { done: true }
    }
}

function test() {
    for (const item of o) {}
}

test()
// Prints [] as I'd expected

Neither does the async iterator version of the loop:

const o = { 
    [Symbol.asyncIterator]() {
        return this
    },
    next(...args) {
        console.log(JSON.stringify(args))
        return Promise.resolve({ done: true })
    }
}

async function test() {
    for await (const item of o) {}
}

test()
// Prints [] as I'd expected

I'm not sure if this is intentional but if it isn't then it should probably be the case that .return and .throw also receive the change to fix .next.

[Jamesernator]

I should note that the specific part of the spec I'm referring to is this function but more specifically part 5 which calls IteratorNext with value regardless of if one was passed or not.

[domenic]

Yes, this is intended. The adapters aren't meant to cater to strange cases like proxies or argument-length-checking functions as their targets.