А вот это интересный вопрос. unique_ptr<T> означает, что либо T плохо перемещается, либо T& полиморфный; плохо перемещаются большие объекты и объекты с неконтролируемыми ссылками, полиморфные возвраты обычно существенно рантаймовы и завязаны на ввод. Если я ничего не упускаю, то в случае неконтролируемых обратных ссылок нас уже ничего не спасёт, а в остальных (большой или данные для типа читались в рантайме) объект потенциально-асинхронный и логика с лямбдами для него роднее?

Или никогда не возвращать borrowed, а вместо этого передавать их в лямбды :)

Я без примеров потреялся (

Можешь раскрыть мысль про лямбды? Не понимаю

(а) T большой => хотим многопоточить
(б) T зависит от чтения из std::cin => хотим асинхронить
(в) на T создаются и потом стираются ссылки => лайфтаймы не работают
если хотим многопоточить/асинхронить, то обычно мы хотим явно записанную операцию над объектом

не-не-не, я предллагаю не 3 проблемв решать, а одну - висящие ссылки

или я недопонял идею (

всё правильно понял, но есть ли у нас будущее кроме асинхронности и есть ли императивное будущее у асинхронности?

корутины же
все императивные языки пошли этим путём, людям нравится

Существуют ли хорошие кастомные реализации tuple?

А вам для чего? Какую задачу решаете?

Задачу по использованию tuple там, где нет полноценной STL и std::exception, но есть, как минимум, набор собственных type_traits и доп. функций вроде move/forward

Задачу по использованию tuple там, где нет полноценной STL и std::exception, но есть, как минимум, набор собственных type_traits и доп. функций вроде move/forward

Есть вот такой простой tuple, который можно скопировать к себе в порект https://github.com/boostorg/pfr/blob/develop/include/boost/pfr/detail/sequence_tuple.hpp