потому что is_copy_constructible_v<callable_with_members<long long>> == false

Чем rvalue отличается от lvalue?

отношением аллаха

а я правильно понимаю, что semiregular-box из ranges как раз эквивалент optional<>, не обладающий таким требованием, т.к. вместо копирования значения поверх имеющегося сбрасывается до пустого состояния и заново конструирует

Я открываю https://en.cppreference.com/w/cpp/ranges/semiregular_wrapper и второй же строчкой вижу requires std::copy_constructible<T> ...

Действительно, там речь про operator=, перепутал

Тогда Страус Язык... и Принципы...

>difficult concepts
Звучит сомнительно. Как будто с++ простой.

>задания после каждой главы
>Has poor practices

Подскажите, не работоспособность case0 и case2 мне кажется просто багом в языке https://godbolt.org/z/ed2dpk . Есть ли какое-либо обоснование, почему там должно быть произведено копирование? По определению - moved-from state является не досягаемым для клиента состоянием, так что копирование может быть просто опущено, и скажем просто переназначены ссылки для локального объекта.

Компилятор ведь не генерирует конструкторы от const rvalue reference

Поэтому и выбирается ближайший подходящий - const lvalue reference

Вот в этом есть, как мне кажется, недочёт со стороны языка

Явно для такого случая сгенерированный конструктор от rvalue reference не сильно отличается от такового для const rvalue reference, особенно учитывая, что конструируется объект с const квалификатором

призываю @webreh , он особенно не любит const&&

А мне вот кажется, что все логично.
Rvalue reference указывает на объект который уже не нужен и скоро помрет и позволяет пользователю делать что угодно с этим объектом (главное, после всех манипуляций оставить его в “разрушаемом” состоянии), обычно это подразумевает вытягивание всего внутреннего состояния в другой объект.
Но что по такой идеологии можно сделать с const rvalue reference? Ничего, ведь состояние этого временного объекта то поменять нельзя. Фактически ситуация становится аналогичной ситуации с const lvalue reference, так собсна зачем генерировать тогда дополнительный конструктор?

Я скорее за конструктор вида: T(const T&&) const noexcept в данном случае, он бы мог означать продолжение жизни объекта, но под другим именем

Фактически проблема возникает только тогда, когда T содержит rvalue reference члены

Что, по какой-то причине (до которой сейчас уже не могу догадаться, башка дырявая) прямо сильно отличается от случая с lvalue reference членами. Прошу подсказки!