concept MyIntf = requires(T t) { .....
Становящаяся довольно обычной идиома "проверить что класс реализует свой статический интерфейс".
class MyClass final { ..... };
static_assert(MyIntf<MyClass>);
Никто не собирается её в ближайшее время засахаривать до чего-то вроде:
class MyClass final implements(MyIntf) { ..... };
Может уже лежит какой-нибудь пропозал? Или может уже предлагали и отвергли?
А зачем? Не вижу достаточного профита, чтобы усложнять и без того очень большой язык и вводить новые ключевые слова
я предлагал Concept struct A; которое означает что структура и все её специализации должны удовлетворять интерфейсу.
Ну типа разрешить вешать только на primary template и ограничивать так все специализации — вроде ничего ужасного.
А что с частичными специализациями? Тут проблема в том, что семантически (в идеальном мире) хотелось бы, чтобы проверка работала для любой из возможных специализаций. А в современных плюсах максимум, что мы можем гарантировать – для любой инстанцированной специализации и получается не очень честно по отношению к пользователю, который пишет template<typename> class MyClass final implements(MyIntf) { ..... }; Отдельный static_assert в этом плане честнее
ну так если не удовлетворяет после инстанцирования сразу ошибка компиляции
Если мы не инстанцировали шаблон – мы не получим ошибку. Если мы инстанцировали его, мы всё ещё можем не получить ошибку, которая возникает в других специализациях Хотелось бы, чтобы новый вводимый языковой инструмент использовался для менее шатких и ненадёжных вещей, чтобы его потом не переделывать
мы пишем ограничение и получаем шаблон, специализации которого точно соответствуют концепту
Я понимаю, что ты хочешь донести. Но указываю на концептуальную проблему в семантике этой фичи
https://github.com/cpp-ru/ideas/issues/471
Обсуждают сегодня