Использование для ожидания ... с синхронными итерациями

MDN говорит, что for await...of есть два варианта использования:

for await...ofОператор создает петлю итерации асинхронной итерации объектов, а также на итерируемых синхронизации, ...

Ранее я знал о первом: использование асинхронных итераций Symbol.asyncIterator. Но сейчас меня интересует последнее: синхронные итерации.

Следующий код выполняет итерацию по синхронной итерации - массиву обещаний. Похоже, блокирует прогресс на выполнение каждого обещания.

async function asyncFunction() {
    try {
        const happy = new Promise((resolve)=>setTimeout(()=>resolve('happy'), 1000))
        const sad = new Promise((_,reject)=>setTimeout(()=>reject('sad')))
        const promises = [happy, sad]
        for await(const item of promises) {
            console.log(item)
        }
    } catch (err) {
        console.log(`an error occurred:`, err)
    }
}

asyncFunction() // "happy, an error occurred: sad" (printed in quick succession, after about 5 seconds)

Поведение похоже на ожидание каждого обещания по очереди, согласно логике, показанной ниже. Это утверждение верно?

async function asyncFunction() {
    try {
        const happy = new Promise((resolve)=>setTimeout(()=>resolve('happy'), 1000))
        const sad = new Promise((_,reject)=>setTimeout(()=>reject('sad')))
        const promises = [happy, sad]
        for(let p of promises) {
            const item = await p
            console.log(item)
        }
    } catch (err) {
        console.log(`an error occurred:`, err)
    }
}

asyncFunction() // "happy, an error occurred: sad" (printed in quick succession, after about 5 seconds)

Я спрашиваю , потому что этот образец коды имеет проводную до ловушки неявного отказа , что Promise.allи Promise.allSettledизбежать, и это мне кажется странным , что эта модель будет явно поддерживается языком.

window.addEventListener('unhandledrejection', () => {
  console.log('unhandled rejection; `sad` was not being awaited at the time it rejected')
})

async function asyncFunction() {
    try {
        const happy = new Promise((resolve)=>setTimeout(()=>resolve('success'), 1000))
        const sad = new Promise((_,reject)=>setTimeout(()=>reject('failure')))
        const promises = [happy, sad]
        for(let p of promises) {
            const item = await p
            console.log(item)
        }
    } catch (err) {
        console.log(`an error occurred:`, err)
    }
}

asyncFunction() // "unhandled rejection; `sad` was not being awaited at the time it rejected" (after about zero seconds), and then "happy, an error occurred: sad" (printed in quick succession, after about 5 seconds)

Да, это странно, и вы не должны этого делать. Не повторяйте массивы обещаний, это в точности приводит к проблеме необработанных отклонений, о которой вы упоминали .

Так почему это поддерживается на языке? Для продолжения небрежно обещаю семантику.

Вы можете найти точное обоснование в этом комментарии к проблеме, обсуждающей эту часть предложения :

Я думаю, что мы должны вернуться к этому, Symbol.iteratorпотому что наша текущая семантика Promise предназначена для того, чтобы позволить вещам синхронизации использоваться как асинхронные вещи. Вы могли бы назвать это "разгильдяйством". Это соответствует логике @ грунтовых вод, описанной выше , но я просто хочу объяснить параллели более подробно.

«Цепная» семантика - .thenэто все об этом. Вы можете вернуть обещание .thenили скалярное значение; все то же самое. Вы призываете Promise.resolveне оборачивать что-либо в Обещание, а приводить что-то к Обещанию - получить асинхронное значение, когда у вас есть что-то или другое.

Семантика asyncи awaitвсе о том, чтобы быть небрежным, а также. Вы можете добавить awaitлюбое не-Promise выражение в асинхронную функцию, и все работает отлично, точно так же, за исключением того, что вы передаете управление очереди заданий. Точно так же, вы можете «оборонительно» расставить async все, что захотите, до тех пор, пока вы получите awaitрезультат. Если у вас есть функция, которая возвращает обещание - что угодно! вы можете сделать это asyncфункцией, и с точки зрения пользователя ничего не изменится (даже если технически вы получите другой объект Promise).

Асинхронные итераторы и генераторы должны работать одинаково. Точно так же, как вы можете ожидать значения, которое, случайно, не было Обещанием, разумный пользователь мог бы ожидать, что сможет yield*синхронизировать итератор в асинхронном генераторе. for awaitЦиклы также должны «просто работать», если пользователь защищенно помечает цикл таким образом, думая, что он может получить асинхронный итератор.

Я думаю, что было бы важно сломать все эти параллели. Это сделало бы асинхронные итераторы менее эргономичными. Давайте обсудим это в следующий раз, когда асинхронные генераторы / итераторы появятся в повестке дня TC39.

sadОбещание не быть под awaitред когда он терпит неудачу - что потребности кода , чтобы закончить ожидание , happyпрежде чем он может начать ждать sad. sadОбещание не удается , прежде чем happyрешает. ( Promise.allинструмент лучше подходит для этого варианта использования)