шаблон с лямбдой в качестве уникального параметра по умолчанию для каждого экземпляра

Question

Я ищу способ автоматически сделать параметр шаблона по умолчанию уникальным каждый раз, когда создается экземпляр шаблона.Поскольку объекты безымянных функций, создаваемые лямбда-выражениями, имеют разные типы, я подумал о том, чтобы как-то их принять.С недавними изменениями в стандартном удалении ошибок «Лямбда-выражение не должно появляться в ограничении ... аргумента шаблона» (см. Формулировка лямбда-выражений в неоцененных контекстах ) оно выглядело какотличная идея.Итак, я написал следующий своего рода рабочий фрагмент, который компилируется на последних gcc и clang :

#include <type_traits>

template<void ( * ) (void) = [](){}> class
unique final {};

static_assert(false == ::std::is_same_v<unique<>, unique<>>);

int main()
{
    return 0;
}

Это жизнеспособный подход или один из тех, "неправильно сформированных, диагностика не требуется"падежи?

Некоторый дополнительный контекст: я хочу использовать это для реализации определений строгого типа в стиле Ады, которые должны работать в одной единице перевода без ручного изобретения уникальных тегов, которые в противном случае были бы неиспользованными:

struct _tag_WowInt {};
using Int = type<int, _tag_WowInt>;
struct _tag_SoUnique {};
using DifferentInt = type<int, _tag_SoUnique>;

Upd1: я хотел бы отметить, что подходы, включающие __COUNTER__ или подобные макросы, не будут работать в общем случае, потому что они будут расширены препроцессором только один раз, а не даст уникальных типов при использовании внутри шаблонанапример .

Answer 1

Я считаю, что вы правы, мне кажется, что это "плохо сформировано, никакой диагностики не требуется".Я думаю, что это покрыто [temp.res / 8.4] и [temp.res / 8.5] :

(8.4) - гипотетическая реализацияшаблона, следующего непосредственно за его определением, будет неправильно сформирован из-за конструкции, которая не зависит от параметра шаблона, или

(8.5) - интерпретация такой конструкции в гипотетической реализации составляет отличается от интерпретации соответствующей конструкции в любой фактической реализации шаблона .[ Примечание : это может произойти в следующих ситуациях:

(8.5.1) - тип, используемый в независимом имени, является неполным в точке, в которой определен шаблонно завершается в тот момент, когда выполняется создание экземпляра, или

(8.5.2) - поиск имени в определении шаблона нашел объявление использования, но поиск в соответствующей области действия в создании экземпляране находит никаких объявлений, потому что объявление-использования было расширением пакета, а соответствующий пакет пуст или

(8.5.3) - экземпляр использует аргумент по умолчанию или аргумент шаблона по умолчанию, который не был определен вточка, в которой был определен шаблон, или

(8.5.4) - для вычисления константного выражения в экземпляре шаблона используется

(8.5.4.1) - значение константного объекта целогоили тип перечисления с незаданной областью или

(8.5.4.2) - значение объекта constexpr или

(8.5.4.3) - value из ссылки или

(8.5.4.4) - определение функции constexpr, и этот объект не был определен при определении шаблона, или

(8.5.5) - aшаблон класса используется специализация шаблона класса или переменный шаблон, который указывается независимым идентификатором simple-template-id, и он либо создается из частичной специализации, которая не была определена при определении шаблона, либо называет явную специализациюэто не было объявлено, когда шаблон был определен.- конечная заметка ]

Несмотря на то, что ваш пример использования явно не указан в примерах примечания, в моем понимании требование подразумевает, что unique<> должно относиться к тому жевещь во всей программе, в противном случае она плохо сформирована, диагностика не требуется.

Это было CWG1850 .Комитету, похоже, не нравится этот вид метапрограммирования.Счетчик constexpr больше не работает в новых версиях компиляторов.