Через внешнюю функцию выгоднее, в общем случае

Из-за ADL

Если вкратце, то рассказывается про существующие популярные механизмы для реализации точек кастомизации и их слабые стороны (в разных аспектах), а ближе к концу предлагается новый механизм (основанный на существующих возможностях языка, без каких-то изменений), который лишён большей части недостатков.

Использует ADL, ниблоиды, не захламляет глобальный неймспейс, расширяем различными способами, хорош в композиции и так далее. Лучше посмотреть доклад :)

касательно tag_invoke, если я не ошибаюсь Boost.asio дополняют библиотеку чтобы поддерживать executors, и механизм кастомизации будет tag_invoke

ещё tag_invoke впилили в boost::json, как я видел

Вопрос, возможно supaproшный. Для корутин из С++20 необходима ОС или можно на бар-метал развернуть?

интересно то, что если в какой-то момент завезут в стандарт (с тем же именем), то ни один механизм не сломается. просто в реализации буста поменяют details::tag_invoke на std::tag_invoke (но будет работать даже без замены - без конфликтов)

Специально так и делают же, в стандарт с буста тянут фичи

Винни бомбил на счет этого, он хочет что то типа polyfills в джаваскрипте, типа чтобы автоматически проставлялось правильное

я не об этом.
например при переезде с boost::shared_ptr надо менять неймспейс.
для переезда с boost:tag_invoke на std::tag_invoke ничего менять не нужно

у него проблемы были с standalone/boost/std, т.е. чтобы на макросах не писать, какие то безопасные и удобные макросы. Там была еще проблема с header-only, но в нее я как то не вник

не знаком с polyfills, можно подробнее?

скажем мы живем в реальности где internet explorer существует (в нашей реальности) у которого имплементация движка сильно отличается от других, и надо писать мосты чтобы автоматически либо вызывалась правильная функция из стандартного движка, либо на мост функцию которая сделает правильно в эксплорере. Или скажем когда используешь новую фишку, которую можно эмулировать старым функционалом, чтобы при использовании автоматически правильная имплементация была вызвана

короче что то вроде облегчения выбора бэкэнд библиотеки

если я правильно помню в конце решили что это дело системы сборки, вроде через cmake оставили опцию

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

Подозреваю, что теоретически можно развернуть, ибо это просто трансформация кода. А во что трансформация - уже ты сам реализуешь. Тут правда может быть нюанс про дин. алокации, так как в общем случае корутины аллоцируют в куче.

По моему там корутины ещё требуют каких то хедеров вне фристендинга

Мне казалось, что проблем будет больше из-за наличия promise механизма, или он не требует каких либо примитивов синхронизации ос внутри?