Немного шутеечек от стандартной библиотеки libstdc++ https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/include/std/chrono#L2316

Кароче: работает - не трогай

Привет! А подскажите пожалуйста где можно найти хорошую реализацию FSM для встраиваемых систем. Из требований и возможностей: C++ 17, Система с ~128KB RAM и неограниченным Flash, без heap allocation, с возможностью передачи параметров через контекст событий(контекстом). Boost со своей реализацией не хочется трогать. Склоняюсь больше к использованию variant

Вот тут смотрел предлагаемые реализации. Не знаю насколько подходит для жизни. https://youtu.be/gKbORJtnVu8

Спасибо! Мне уже выше написали, что нужно пересмотреть саму идею, что лучше ограничивать входные параметры, а не выход функции. Соглашусь с вами, хотя для целей само-документирования кода было бы здорово и ограничить выход. Хотел что-то такое замутить с автоматическим placeholder, но выражение типа "template<typename MapItem, typename MapFn> Activity<MapItem> auto map(MapFn&&)" проставляет совсем не тот MapItem. Он почему-то получается дважды вложенным в Activity, а так было бы красиво. Тут я совсем не понимаю, как работают placeholder и связка концепта с auto. Видео посмотрю

Считайте, что концепт это точный аналог интерфейса, только для компильтайма

Если я вас правильно понимаю, вы хотите записать прямо в язык что-то вроде
/*unspecified but explicitly convertible to bool*/ foo()
Но язык пока не может ничего сделать с подобной конструкцией, для него foo возвращает конкретный тип, никакого unspecified

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

Заглянул в исходники ranges для GCC. Там обычное дело, когда выходной результат автовыводится через auto. Видимо, так и мне следует делать. Значит, накладываем ограничения только на вход функций. Ну, это тоже шаг вперед, причем огромный.

Ты понял, что я тебе написал? :)
https://t.me/ProCxx/401590

"ограничение на выход функции" это обязательство из документации, для языка оно вообще не имеет смысла

У тебя, кажется, какое-то заблуждение вроде "сигнатура функции является формой её документации" в голове.

Не надо сочинять! Это вполне ожидаемая вещь. Но нет, так нет

И это уже на грани перехода на личности

Вовсе нет, просто ошибка находится уже где-то в общей логике происходящего. Что вообще может означать требование на возвращаемое значение функции, которое указано точно.

ConvertibleToBool int foo()

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

template <typename T> auto foo() {}
template <typename T> decltype(auto) foo() {}

перед нами уже разные шаблоны функции, и

template <typename T> ConvertibleToBool auto foo() {}

было бы еще одним разным шаблоном функции

Так что это не "ожидаемая вещь", это прямо-таки "а язык-то хотя бы от этого полностью не сломается?" вещь

Такое ограничение все ещё можно написать
И можно было бы его оставить в тестах

Потому что это требование к разработчику приложения, чем к его пользователю