Почему мы требуем, требует, требует?

Потому что этого требует грамматика. Оно делает.

Ограничение requires не обязано использовать выражение requires. Он может использовать любое более или менее произвольное логическое постоянное выражение. Следовательно, requires (foo) должно быть законным requires ограничением.

requires выражение (то, что проверяет, соответствуют ли определенные вещи определенным ограничениям) - это отдельная конструкция; он просто введен тем же ключевым словом. requires (foo f) будет началом допустимого requires выражения.

Вы хотите, чтобы, если вы используете requires в месте, которое принимает ограничения, вы должны иметь возможность сделать "ограничение + выражение" из предложения requires.

Итак, вот вопрос: если вы поместите requires (foo) в место, подходящее для ограничения requires ... как далеко должен пройти синтаксический анализатор, прежде чем он сможет понять, что это ограничение требует ограничение, а не ограничение + выражение, как вы хотите?

Учти это:

void bar() requires (foo)
{
  //stuff
}

Если foo является типом, то (foo) является списком параметров выражения required, и все в {} является не телом функции, а телом этого requires выражения. В противном случае foo - это выражение в предложении requires.

Что ж, можно сказать, что компилятор должен сначала выяснить, что такое foo. Но C ++ действительно не любит, когда базовое действие по синтаксическому анализу последовательности токенов требует, чтобы компилятор выяснил, что означают эти идентификаторы, прежде чем он сможет понять токены. Да, C ++ контекстно-зависимый, так что это действительно происходит. Но комитет предпочитает по возможности избегать этого.

Так что да, это грамматика.

Ситуация в точности аналогична noexcept(noexcept(...)). Конечно, это больше похоже на плохое, чем на хорошее, но позвольте мне объяснить. :) Начнем с того, что вы уже знаете:

В C ++ 11 есть «noexcept-предложения» и «noexcept-выражения». Они делают разные вещи.

• В предложении noexcept сказано: «Эта функция не должна быть, кроме случаев, когда ... (какое-то условие)». Он переходит к объявлению функции, принимает логический параметр и вызывает изменение поведения объявленной функции.

• noexcept-выражение говорит: «Компилятор, скажите, пожалуйста, ли (какое-нибудь выражение) никакое исключение». Само по себе это логическое выражение. У него нет «побочных эффектов» на поведение программы - он просто запрашивает у компилятора ответ на вопрос «да / нет». "Разве это выражение не кроме?"

Мы можем вложить noexcept-выражение в noexcept-предложение, но мы обычно считаем это плохим стилем.

template<class T>
void incr(T t) noexcept(noexcept(++t));  // NOT SO HOT

Считается лучшим стилем инкапсулировать noexcept-выражение в типаж.

template<class T> inline constexpr bool is_nothrow_incrable_v =
    noexcept(++std::declval<T&>());  // BETTER, PART 1

template<class T>
void incr(T t) noexcept(is_nothrow_incrable_v<T>);  // BETTER, PART 2

В рабочем проекте C ++ 2a есть «requires-clauses» и «requires-expression». Они делают разные вещи.

• В предложении requires сказано: «Эта функция должна участвовать в разрешении перегрузки, когда ... (какое-то условие)». Он переходит к объявлению функции, принимает логический параметр и вызывает изменение поведения объявленной функции.

• requires-выражение говорит: «Компилятор, скажите мне, пожалуйста, ли (какой-то набор выражений) правильно сформирован». Само по себе это логическое выражение. У него нет «побочных эффектов» на поведение программы - он просто запрашивает у компилятора ответ на вопрос «да / нет». "Это выражение правильно сформировано?"

Мы можем вложить requires-выражение в requires-предложение, но мы обычно считаем это плохим стилем.

template<class T>
void incr(T t) requires (requires(T t) { ++t; });  // NOT SO HOT

Считается лучшим стилем инкапсулировать requires-выражение в типаж ...

template<class T> inline constexpr bool is_incrable_v =
    requires(T t) { ++t; };  // BETTER, PART 1

template<class T>
void incr(T t) requires is_incrable_v<T>;  // BETTER, PART 2

... или в концепции (C ++ 2a Working Draft).

template<class T> concept Incrable =
    requires(T t) { ++t; };  // BETTER, PART 1

template<class T>
void incr(T t) requires Incrable<T>;  // BETTER, PART 2

Я думаю, что страница концепций cppreference объясняет это. Я могу математически объяснить, так сказать, почему это должно быть так:

Если вы хотите определить концепцию, вы делаете это:

template<typename T>
concept Addable = requires (T x) { x + x; }; // requires-expression

Если вы хотите объявить функцию, использующую эту концепцию, сделайте следующее:

template<typename T> requires Addable<T> // requires-clause, not requires-expression
T add(T a, T b) { return a + b; }

Теперь, если вы не хотите определять концепцию отдельно, я думаю, все, что вам нужно сделать, это подменить. Возьмите эту деталь requires (T x) { x + x; }; и замените часть Addable<T>, и вы получите:

template<typename T> requires requires (T x) { x + x; }
T add(T a, T b) { return a + b; }

что объясняет механику. Почему лучше всего проиллюстрировать на примере двусмысленности, которая может возникнуть, если мы изменим язык, чтобы принять один requires в качестве сокращения для requires requires.

constexpr int x = 42;

template<class T>
void f(T) requires(T (x)) { (void)x; };

template<class T>
void g(T) requires requires(T (x)) { (void)x; };

int main(){
    g<bool>(0);
}

Просмотрите в Godbolt, чтобы увидеть предупреждения компилятора, но обратите внимание, что Godbolt не пытается выполнить этап связывания, который в этом случае потерпит неудачу.

Единственная разница между f и g - это удвоение «требует». И все же семантическая разница между f и g огромна:

• g - это просто объявление функции, f - полное определение
• f принимает только bool, g принимает все типы, приводимые к void
• g затеняет x своим собственным (излишне заключенным в скобки) x, но
• f приводит глобальный x к заданному типу T

Очевидно, мы бы не хотели, чтобы компилятор автоматически менял одно на другое. Эту проблему можно было бы решить, используя отдельное ключевое слово для двух значений requires, но, когда это возможно, C ++ пытается развиваться, не вводя слишком много новых ключевых слов, поскольку это ломает старые программы.

Я нашел комментарий Эндрю Саттона (одна из концепций авторы, которые реализовали его в gcc), чтобы быть весьма полезными в этом отношении, поэтому я подумал, что просто процитирую его здесь полностью:

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

Однако в 2016 году было предложено ослабить это ограничение [Примечание редактора: P0266]. Обратите внимание на зачеркнутый абзац 4 в разделе 4 статьи. И таким родился требует требует.

По правде говоря, я никогда не реализовывал это ограничение в GCC, так что это всегда было возможно. Я думаю, что Уолтер, возможно, обнаружил это и нашел его полезным, что привело к этой статье.

Чтобы никто не подумал, что я неуязвим к написанию требований дважды, я потратил некоторое время, пытаясь определить, можно ли это упростить. Короткий ответ: нет.

Проблема в том, что после списка параметров шаблона необходимо ввести две грамматические конструкции: очень часто выражение ограничения (например, P && Q) и иногда синтаксические требования (например, requires (T a) { ... }). Это называется требованием-выражением.

Первое требование вводит ограничение. Второй требует вводит выражение requires. Так складывается грамматика. Меня это совершенно не смущает.

В какой-то момент я попытался свести их к одному требованию. К сожалению, это приводит к серьезным трудностям при синтаксическом анализе. Вы не можете легко сказать, например, если ( после требования обозначает вложенное подвыражение или список параметров. Я не верю, что существует идеальное устранение неоднозначности этих синтаксисов (см. Обоснование единого синтаксиса инициализации; эта проблема тоже существует).

Итак, вы делаете выбор: make требует ввести выражение (как сейчас) или заставить его ввести параметризованный список требований.

Я выбрал текущий подход, потому что большую часть времени (как и почти 100% времени) мне нужно что-то другое, кроме выражения requires. И в чрезвычайно редком случае мне нужно было выражение requires-expression для специальных ограничений, я действительно не возражаю написать это слово дважды. Это очевидный показатель того, что я не разработал достаточно прочную абстракцию для шаблона. (Потому что, если бы это было так, у него было бы имя.)

Я мог бы выбрать, чтобы в требованиях вводилось выражение-требование. Это на самом деле хуже, потому что практически все ваши ограничения начнут выглядеть так:

template<typename T>
  requires { requires Eq<T>; }
void f(T a, T b);

Здесь второе требование называется вложенным требованием; он оценивает свое выражение (другой код в блоке выражения required не оценивается). Я думаю, что это намного хуже, чем статус-кво. Теперь вам нужно писать везде, где требуется дважды.

Я мог бы также использовать больше ключевых слов. Это проблема сама по себе - и это не просто потеря велосипеда. Возможно, существует способ «перераспределить» ключевые слова, чтобы избежать дублирования, но я не задумывался об этом серьезно. Но сути проблемы это не меняет.

Потому что вы говорите, что у вещи A есть требование B, а у требования B есть требование C.

Вещь A требует B, который, в свою очередь, требует C.

Сама оговорка "требует" чего-то требует.

У вас есть вещь A (требуется B (требуется C)).

Мех. :)