Зачем использовать std :: forward в концепциях?

Разве мы не хотим вызывать своп с lvalues ​​[…]

Это очень хороший вопрос. В частности, вопрос разработки API: какое значение или значения должен придавать разработчик библиотеки концепций параметрам своих концепций?

Краткий обзор требований Swappable. То есть фактические требования, которые уже присутствуют в сегодняшнем Стандарте и были здесь еще до концептуального облегчения:

• Объект t является можно заменить объект u если и только если:
  • […] Выражения swap(t, u) а также swap(u, t) действительны […]

[…]

Rvalue или lvalue t можно заменить, если и только если t можно заменить на любое значение rvalue или lvalue, соответственно, типа T,

(Отрывки из Swappable требования [swappable.requirements] чтобы сократить множество несущественных деталей.)

Вы это поймали? Первый бит дает требования, которые соответствуют вашим ожиданиям. Очень просто превратить в реальную концепцию † тоже:

^{†: пока мы готовы игнорировать тонну деталей, которые находятся за пределами нашей компетенции}

template<typename Lhs, typename Rhs = Lhs>
concept bool FirstKindOfSwappable = requires(Lhs lhs, Rhs rhs) {
swap(lhs, rhs);
swap(rhs, lhs);
};

Теперь, что очень важно, мы должны немедленно заметить, что эта концепция поддерживает ссылочные переменные прямо из коробки:

int&& a_rref = 0;
int&& b_rref = 0;
// valid...
using std::swap;
swap(a_rref, b_rref);
// ...which is reflected here
static_assert( FirstKindOfSwappable<int&&> );

^{(Теперь технически Стандарт говорил с точки зрения объектов, ссылки на которые нет. Поскольку ссылки не только относятся к объектам или функции но призваны прозрачно отстаивать их, мы на самом деле предоставили очень желательную функцию. Практически говоря, мы сейчас работаем с точки зрения переменные, не только объекты.)}

Здесь очень важная связь: int&& является объявленным типом наших переменных, а также фактическим аргументом, передаваемым в концепцию, которая, в свою очередь, снова становится объявленным типом нашего lhs а также rhs требует параметров. Имейте это в виду, когда мы копаем глубже.

Coliru демонстрация

А что насчет второго бита, в котором упоминаются lvalues ​​и rvalues? Ну, здесь мы больше не имеем дело с переменными, а вместо этого с точки зрения выражения. Можем ли мы написать концепцию для этого? Ну, есть определенная кодировка типа выражения, которую мы можем использовать. А именно тот, который используется decltype так же как std::declval в другом направлении. Это приводит нас к:

template<typenaome Lhs, typename Rhs = Lhs>
concept bool SecondKindOfSwappable = requires(Lhs lhs, Rhs rhs) {
swap(std::forward<Lhs>(lhs), std::forward<Rhs>(rhs));
swap(std::forward<Rhs>(rhs), std::forward<Lhs>(lhs));

// another way to express the first requirement
swap(std::declval<Lhs>(), std::declval<Rhs>());
};

С чем ты столкнулся! И, как вы узнали, концепция должна использоваться по-другому:

// not valid
//swap(0, 0);
//     ^- rvalue expression of type int
//        decltype( (0) ) => int&&
static_assert( !SecondKindOfSwappable<int&&> );
// same effect because the expression-decltype/std::declval encoding
// cannot properly tell apart prvalues and xvalues
static_assert( !SecondKindOfSwappable<int> );

int a = 0, b = 0;
swap(a, b);
//   ^- lvalue expression of type int
//      decltype( (a) ) => int&
static_assert( SecondKindOfSwappable<int&> );

Если вы обнаружите, что это неочевидно, взгляните на соединение в игре на этот раз: у нас есть lvalue-выражение типа int, который становится закодированным как int& аргумент концепции, которая восстанавливается до выражения в нашем ограничении std::declval<int&>(), Или более окольным путем, std::forward<int&>(lhs),

Coliru демонстрация

То, что появляется в записи cppreference, является сводкой Swappable Концепция, указанная в диапазонах TS. Если бы я угадал, я бы сказал, что ТС Рэнджес решил дать Swappable Параметры для выражений по следующим причинам:

• мы можем написать SecondKindOfSwappable с точки зрения FirstKindOfSwappable как указано в следующем ^около:

  template<typename Lhs, typename Rhs = Lhs>
  concept bool FirstKindOfSwappable = SecondKindOfSwappable<Lhs&, Rhs&>;
  

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

• ограничение на swap(std::forward<Lhs>(lhs), std::forward<Rhs>(rhs)) как ожидается, будет достаточно важным сценарием; Вдобавок ко мне это приходит в бизнес, такой как:

  template<typename Val, typename It>
  void client_code(Val val, It it)
  requires Swappable<Val&, decltype(*it)>
  //                           ^^^^^^^^^^^^^--.
  //                                          |
  //  hiding an expression into a type! ------`
  {
  ranges::swap(val, *it);
  }
  

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

Но почему по большей части?

Потому что существует третий тип концептуального параметра: тип, обозначающий … тип. Хороший пример тому DerivedFrom<Derived, Base>() какое значение не дает вам допустимых выражений (или способов использования переменных) в обычном смысле.

Фактически, например, Constructible<Arg, Inits...>() первый аргумент Arg можно интерпретировать двумя способами:

• Arg обозначает тип, то есть принимает конструктивность как неотъемлемое свойство типа
• Arg является объявленным типом создаваемой переменной, то есть ограничение подразумевает, что Arg imaginary_var { std::declval<Inits>()... }; является действительным

Завершу свое личное замечание: я думаю, что читатель не должен (пока) делать вывод, что он должен писать свои собственные концепции одинаково только потому, что концепции над выражениями представляются, по крайней мере, с точки зрения автора концептов, как надмножество понятий над переменными.

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