нужно будет, да.

Ну если такая задача решается без корутин, это либо callback hell либо в тот же таск сложен стейтмашин, а может даже комбинация оных. В любом случае множество разрозненных функций (спагетти), где состояние явно упаковано либо в сам таск либо в callback. А тут компилятор сам вычислит что есть состояние и сам всё упакует и состыкует.

Но иногда мне кажется это порождает и вопросы. Например в линейном коде мы обычно не задумываемся о времени жизни локальных переменных. Какой нибудь intermediate result... Пусть мрёт в конце, со всеми. А coroutines кажется заставят подходить к этому более ответственно. Не нужен, избавься, иначе будет висеть в контексте до конца. Изменить семантику destruct on scope exit на destruct after last use нельзя, сайд эффекты...

Кстати, может полезно было бы (как наверное и понадобится для destructive move) сделать явный scope elimination. Убить досрочно. Кандидаты вычислимы, их надо только в scope destruct опционально чистить (да, с одной стороны дорого, плюс флажки). Но с другой стороны мб stack reuse. И плюшки как от unique_lock в сравнении со scope_lock.

На сколько я помню свои эксперименты, компилятор в простых случаях выкидывал переменные, которые пересекали suspend point без необходимости.

Если я правильно понял в расте эта функция называется drop.

На самом деле, мне кажется, что многие из тех кто не понимает зачем нужны корутины просто не жили в callback hell'е. Вероятно они пишут код не требовательный к производительности и поэтому блокирующий io и по треду на задачу является нормальным решением в их задачах.

А какая разница, ну будет вместо callback hell, будет coroutine hell, тебе будет легче?
Суть то в том, что hell ...

В корутинах это деталь реализации. В callback hell'е все кишки наружу торчат.

Это слово hell есть отражение внутренней сложности приложения, и эту сложность никакая фича языка не снимает.

Мне так думается

Корутина это абстракция более высокого уровня, поэтому она понижает сложность там где не требуется лезть в кишки.

ну хотя бы код читать проще будет

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

я правильно понимаю, что стандартные unordered контейнеры поддерживают гетерогенный лукап, но при этом стандартные std::hash и std::equal_to<void> не объявляют is_transparent, то есть для гетерогенного поиска придется дописывать свои Hash/Equal?

Верно. Только equal_to<void> - transparent, а hash - нет

не вижу тут is_transparent
https://en.cppreference.com/w/cpp/utility/functional/equal_to
косяк cppreference или всё-таки не гетерогенный?

ок

то есть для гетерогенного поиска по умолчанию нужно чтобы условный std::hash<std::string> принимал std::string_view )