This is debatable. Banning iterables of thenables should be an option.

Eh, kind of... in any case, I was going off of#8858 (comment). It's easy enough to add an option to allow iterables of thenables, though I'm -0.5 on doing so.

In lieu of an option, can we add more motivation to the docs (as what I said in that comment)?

Good point! Made some changes around this 👍

bleh - I guess this isn't always a good idea, particularly with possibly infinite iterables. But, then again, why would you have an infinite sync iterable of promises? Thinking out loud.

Can we only offer this suggestion if the iterator result is not thenable?

I don't think so because we'd needgetIterationTypesOfIterable() orgetIteratedTypeOrElementType or similar from TS none of which is exposed on thechecker.

If we check arrays and tuples specifically, i.e. known iterables, this is silly since

for(constpromisedValueofawaitPromise.all(promises)){}

is a much better suggestion in those cases (sinceawaiting in the loop is generally problematic for exception handling given a non-lazy array of promises)

Whereas with lazy sync-iterables of promises, which I don't know if we can detect, it may be better to do

for(constpromiseofyieldPromises()){constpromisedValue=awaitpromise;}

I guess the only thing that's unambiguous here is that if you have an array or tuple of non-thenables, this suggestion is good. Maybe that's the only situation where we give a suggestion?