да, наверно прокатит

слушайте, а есть идея. Допустим есть у нас

class T {};
concept C; // C<T> -> true
auto foo(C auto x) { ... }

Скажем любой U, повторяющий интерфейс T,  будет удовлетворять C. Допустим мы хотим именно eager (блин как это слово на русский переводится?) трейты - чтобы U удовлетворял C только если явно это укажет
А если как-нить так:

explicit concept C; // "explicit" keyword here
class T : C { ... };
class U { ... };
auto foo(explicit C auto x) { ... } // or maybe here
foo(T{}); // ok
foo(U{}); // failure

Только нужен трейт template<typename T, typename ...Types> constexpr bool any_of = (std::is_same_v<T, Types> || ...);.

это другое

C не должен знать про T/U

поправил пример

class T {};
concept C; // C<T> -> true
auto foo(C auto x) { ... }

мне это чем-то напоминает концепты, которые разрабатывались для 11 стандарта. в последнем или предпоследнем hopl страуструп подробно про них рассказывает

class T {};
concept C; // C<T> -> true
auto foo(C auto x) { ... }

Это похоже на протоколы свифта

Но какие у этого преимущества?

class T {};
concept C; // C<T> -> true
auto foo(C auto x) { ... }

Тут смотри какое дело. При кажущейся похожести подобной структуры это немного не концепты, а трейты (что характерно, можно добиться эффекта через специализацию шаблона). Я не помню терминов, но есть разница между подходом "сущность определяется содержимым" (как struct в C) и "сущность определяется именем" (как struct в С++). Концепты это первое, и это само по себе кажется очень важным - концепт это не более, чем соглашение вот этот набор свойств называть вот так, в которое при помощи tag-ов дописаны свойства, которые в текущий момент не могут быть записаны в языке как утверждения, после чего концепт не может страдать архитектурными ошибками вида "в этом трейте требуется лишнее" - концепт это только имя.

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

Так у вас же никто не забирает наследование и теги, тегайте тегами, трейтьте трейтами

Наследование забирают, вместо него отношение частичного порядка на множестве концептов, то самое по принципу Лисков "A является B"

Наследование можно использовать как тег

Ой да всем плевать на лисков, кажется это в какой-то красной книжке написано

Но не нужно, тегами нужно закрывать свойства, которые являются неописываемыми в языке математическими утверждениями (скажем, коммутативность сложения)

Ты хочешь ещё один квалификатор для комутативности?

Спецификатор*

Я не смогу и так все существующие перечислить