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

К>Понятное дело, что это извращения с кодом, и вообще, когда допилю, (надеюсь, к Дню Программиста), сделаю статью на хабре.
К>Но сейчас мне просто нужна обратная связь по коду.

template<Rule auto... ps> struct rules {
    REPRESENTS(Rule)

    constexpr RuleOutput auto operator()(RuleInput auto t) const {
        return (not_matched_yet{t} >> ... >> ps);
    }
};

Вот в этом месте я бы не поленился и рядом с шаблоном класса, определил бы ещё и шаблон объекта класса:

template<Rule auto... ps> struct Rules {
   // . . . 
};
template <Rule auto... ps> constexpr Rules<ps...> rules.

Тогда при использовании rules можно будет убрать мозолящие глаза пустые фигурные скобки (инициализаторы).

А в нешаблонных классах имя класса можно и вовсе опускать:

struct {
   // Здесь функциональные операторы - сколько угодно и какие угодно.
} inline constexpr foo;

Такие функциональные объекты могут быть как параметрами обычных функций, так и параметрами шаблонов.

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

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

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

К>Понятное дело, что это извращения с кодом, и вообще, когда допилю, (надеюсь, к Дню Программиста), сделаю статью на хабре.
К>Но сейчас мне просто нужна обратная связь по коду.

template<Rule auto... ps> struct rules {
    REPRESENTS(Rule)

    constexpr RuleOutput auto operator()(RuleInput auto t) const {
        return (not_matched_yet{t} >> ... >> ps);
    }
};

Вот в этом месте я бы не поленился и рядом с шаблоном класса, определил бы ещё и шаблон объекта класса:

template<Rule auto... ps> struct Rules {
   // . . . 
};
template <Rule auto... ps> constexpr Rules<ps...> rules.

Тогда при использовании rules можно будет убрать мозолящие глаза пустые фигурные скобки (инициализаторы).

А в нешаблонных классах имя класса можно и вовсе опускать:

struct {
   // Здесь функциональные операторы - сколько угодно и какие угодно.
} inline constexpr foo;

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

На основе одного шаблонного класса можно определить несколько шаблонов объектов класса со специальными именами и тем самым избавиться от макросов. Как по мне, макросы здесь выглядят как ложка дёгтя.

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