Здравствуйте, rg45, Вы писали:

R>Вот в этом месте я бы не поленился и рядом с шаблоном класса, определил бы ещё и шаблон объекта класса:
R>Тогда при использовании rules можно будет убрать мозолящие глаза пустые фигурные скобки (инициализаторы).

Была такая мысль, но в какой-то момент, на какой-то черновой итерации я её выбросил, а потом забыл вернуться.

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

Если это сократит время компиляции, — то добавлю.

TODO проверить выгоды от констант.

R>А в нешаблонных классах имя класса можно и вовсе опускать:
R>Такие функциональные объекты могут быть как параметрами обычных функций, так и параметрами шаблонов.

Я таким образом делаю инлайновые классы, — например, в макросе NAMED_RULE.
Но тут именованность как раз является фичей, потому что читать бесконечные test_blablabla::unnamed::auto123::..... — мучительно.

TODO прикрутить туда автоматические имена (с помощью __LINE__ и __COUNTER__).
И автоматически именовать RULES, опять-таки, чтобы сокращать выхлоп ошибок компилятора.

R>В итоге получается код аккуратнее и чище.

Чистить код у меня тоже в планах )))
В первую очередь это proof of concept.

Буквально на днях я проверил концепцию "что если переписать всё на монаде Either", и оказалось, что это ОЧЕНЬ плохо, компиляция улетает в небеса.

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

R>P.S. Вообще подход полезный, как альтернатива традиционному рантайм полиморфизму — для декомпозиции и структурирования кода, для разложения сложных задач на более простые подзадачи и стратегии. Это потом легко мокается и покрывается юнит тестами.

А разверни тему, пожалуйста.