Обоснование WG21 для отказа от использования квалификаторов ref

Какие документы WG21 объясняют решение не включать квалификаторы ссылок в большинство классов стандартных библиотек?

Пример, который выиграет от такого включения:

template <class C1, class C2>
C1 container_cast(C2&& source)
{
    C1 dest;
    // if constexpr(can do so) dest.reserve(source.size());
    for(auto&& element : std::forward<C2>(source))
    {
        dest.emplace_back(std::forward<decltype(element)>(element));
    }
    return dest;
}

Однако никакие методы доступа к членам контейнера не распространяют на них rvalue, вызывая ненужные копии. Это отличается, например, от std::get(std::tuple) и std::Optional::operator *, которые предоставляют перегрузки всех видов, включая оксюморон «const &&».

(Тесно связано с квалификаторами rvalue ref для контейнеров STL, но вопрос более конкретен.)


person Roman Odaisky    schedule 26.08.2019    source источник
comment
Вам нужен make_move_container, который будет вызывать make_move_iterator для begin/end?   -  person Jarod42    schedule 26.08.2019
comment
Я не могу говорить о намерениях комитета, но для меня состояние, в котором оказался бы исходный контейнер, если бы из этого цикла было выброшено исключение, было бы странным, в Лучший. Так что я согласен с тем, что begin и end не продвигаются к move_iterators по умолчанию и требуют немного больше работы, чтобы выполнить то, что вы хотите.   -  person Frank    schedule 26.08.2019
comment
@Frank, ну, если контейнер был rvalue, значит, никто не ожидал от него ничего, кроме разрушаемости. Это постусловие полностью выполняется, даже если генерируется исключение (конечно, из чего-то другого, кроме конструктора перемещения).   -  person Roman Odaisky    schedule 27.08.2019
comment
@RomanOdaisky Конечно, но факт остается фактом: есть период времени, когда контейнер представляет собой смесь обычных и перемещенных объектов. Даже если этот контейнер вероятно (даже не обязательно) будет жить только во время раскручивания стека, тот факт, что он находится в этом состоянии вне цикла, мне неприятен, и поэтому я не возражаю имея немного трения вокруг этого.   -  person Frank    schedule 27.08.2019
comment
@Frank Я хотел бы узнать, что не нравится Комитету. Учитывая, что результат вызова std::remove_if для lvalue не кажется им неприглядным, я не вижу причин предполагать, что они так сильно заботятся об эстетике контейнеров rvalue.   -  person Roman Odaisky    schedule 27.08.2019