их в C++23
если это не те, которые требуют поддержки как корутины волшебными методами типа set_error, то пусть будут, без них вводить нормальную библиотеку нетворкинга и корутин невозможно
Синтаксис scheduler auto sch и auto [i] сходу кажется немного (но это не точно) странным
так это опциональная вещь которая и сейчас возможна
но в качестве примера хело ворда можно было хотя бы 2 переменные сделать, а то auto [i] не думаю что все сразу поймут че произошло
ох, что то я посмотрел на экзекьюторы. Отчасти полезные идеи, но вот их комбинации через | это же полная дичь, начинается ад для понимающего, тыщу раз повторять аргументы что с чем куда
Ну в плане оверхеда, концепции structured concurrency кажется они делают правильные вещи. Будет ли это юзабельным? Ну для новых проектов наверное есть шанс, для старых вряд ли По самому синтаксису я уже привык, что в плюсах выбирают всегда самый неудобный вариант Ещё меня немного смущает оверхед на variant<tuple<...>, tuple<...>,...> Возможно в будущем с помощью кучи шаблонов (а сколько оно компилится будет??) оптимизируют реализации, но пока то что видел в этом плане весьма печально (для дебаге в том числе) Ещё меня очень смущает, что сейчас пропозалом (собственно переход от 0443 к 2300) вроде бы занимаются люди, которых прежде всего интересует параллельное исполнение, параллельные алгоритмы для тяжёлых вычислений и тд, это меня не особо волнует, а делают для этого
Оно не особо от libunifex отличается, в основном мелочи, если ты про это
Выглядит как пара каких-то других встроенных пропозалов 9999-in-1 Не читая весь пропозал, мне бы показалось что в «scheduler auto sch» scheduler это какой-то концепт, а sch объект ему удовлетворяющий
Не, не обязательно, если Kek это концепт, то в можно сделать метод «void foo(Kek auto kek)», и это будет неявный темплейт Поэтому интуиция сказала что возможно эту конструкцию расширили на весь код с auto
Вообще как-то много всего, давно ведь говорили что фичефриз наступил, а тут какую-то бумагу с овер 9999 новыми понятиями хотят затащить
Я думаю, не стоит спешить с непроверенными идеями, иначе спустя годы опять будем задаваться вопросом, как же так получилось, что у нас есть std::initializer_list, std::async и... std::execution
А что не так с std-async? Где почитать про его проблемы?
Непродуманность его дизайна и неприменимость в реальной разработке
ну как бы идею мусолят лет 10
и за это время язык изменился, а идея видимо нет
Как лоу-левел апи хорошо Для применения обычными разрабами, нужно куча оберток как мне кажется
Обсуждают сегодня