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

стеклес прибить проще

идеальный вариант же. Кому нужны stackless - наконец-то смогут их использовать хоть в каком-то виде. Кому нужны stackful - смогут продолжить использовать их из библиотек

Причина простая. Stackful можно реализовать как библиотечное решение без поддержки новых слов на уровне компилятора, stackless нельзя. Ну или можно через хаки как в Asio, но получается всё равно негибко, и аллокаций не избежать.

Stackful противоречат концепции "you don't pay for what you don't use".

предлагаю выпилить из std умные указатели и впилить GC

найс передергивание, молодец

по той же причине по котороый в стандарте stackless вместо stackfull

Сейчас с корутинами проблема в том, что нужно написать экзекютер + реактор + все примитивы вокруг. В идеале еще и с каким-то обобщенным интерфейсом, чтобы можно было менять их без переписывания всего и вся. Без этого корутинами для асинхронного программирования невозможно пользоваться и это является одним из фокусов комитета на 23 год.

Может быть моя изначальная формулировка была не самой удачной, но Владимир уже отлично ответил за меня.

Это как использовать shared_ptr там, где не нужен ни подсчёт ссылок, ни проверка, жив ли объект.

можно смело идти обмазываться растом и vcpkg

Ну коммитет иногда очень странные вещи принимает. Вон в С++11 добавили future/promise. И так они особо никому не нужны

там же нет GC... и там умные указатели тоже встандати

у меня очень много кода на футуре\промисах. так что не могу согласиться

На тех, что из std, или сторонних/самописных?

и на std в том числе

Интересно. Просто везде, где я с ними работал, использовали свои (seastar) или сторонние (например, boost), потому что и гибче, и мощнее.

для тех случаев, когда гибкость особо не нужна, просто используем std и не паримся. если выполняет свою работу, то и хорошо. второй вариант используемых футур - это бустовые, да

хохмы ради - только сейчас заметил, что cppcoro использует самописную билд-систему :)

Там одно из главных нареканий было на отсутствие .then(). Хотя можно написать свою вспомогательную функцию для этого. По итогу сейчас всё равно всё движется в сторону standalone functions в той же libunifex.