А, понятно ) я не шарю прост

почему?

например std::string::operator+ можно было бы оптимизировать перегружая по ref qualifier'ам

Перегрузка методов по ref qualifier такая же полезная, как и перегрузка свободных функций для const&/&/&&. Просто все забывают про неё, используя лишь const/non-const пару.

Ну синтаксис неочевидный, всё-таки
Завезли бы уже явный self параметр в методы, как в https://wg21.link/p0847r6

Согласен. Неочевидность ещё связана с тем, что this указатель, а не ссылка.
Пропозал стоящий (и не заброшенный, что радует)

Как ярко охарактеризовали этот proposal на днях "nail into the coffin of C++" (https://twitter.com/BarryRevzin/status/1372269034352349188)

хз мне кажется что с момента обозначения && и как универсальной, и как rvalue ссылки уже гвоздей больше не придумаешь )

это впоследствие накрыло медным тазом столько шаблонных трюков...

У такой перегрузки есть очень доброе использование - запрет на вызов метода для rvalue.

Вот например, есть переменная rcu<string> x, обновляемая из разных потоков. Правильное использование переменной:

auto snapshot = x.snapshot();
foo(snapshot->c_str());

А вот неправильное, при котором guard будет уничтожен до того, как мы начнём пользоваться значением и порой будет seg fault:

const auto* ptr = x.snapshot()->c_str();
foo(ptr);

Так вот, с помощью реф квалификаторов, второй кейс можно отлавливать на этапе компиляции и избегать труднодетектируемых ошибок

А есть чтото вроде lock-free heap? Тоесть, например, n потоков сложили 4 2 3 1 6 8 7 9, а один достаёт 1 2 3 4 и блокируется потомучто поток j еще 5 не доложил?

auto snapshot = x.snapshot();
foo(snapshot->c_str());

const auto* ptr = x.snapshot()->c_str();
foo(ptr);

Но при этом не получится вызвать foo(x.snapshot()->c_str()), что вполне валидно (если предположить, что foo не сохраняет указатель).
Напоминает историю с string_view(std::string&&), где решили разрешить foo(get_string()) как раз для того, чтобы избежать лишней переменной

По этой логике и c_str() нужно запретить на &&, ведь мы потенциально можем написать const auto* ptr = get_string().c_str();

Так что здесь есть некоторый компромисс между безопасностью и многословностью.

auto snapshot = x.snapshot();
foo(snapshot->c_str());

const auto* ptr = x.snapshot()->c_str();
foo(ptr);

Так тут как раз же будет & квалифаер , а перегрузка с && отключена. Я это одобряю

Но все рушит const & например если я правильно понял Константина

По хорошему, это должно ловиться компилятором (

Нужна конструкция "объёкт владеет результатом". Например чтобы можно было помечать unique_ptr::operator->() borrowed и получать ошибки компиляции при неправильном использовании

Или никогда не возвращать borrowed, а вместо этого передавать их в лямбды :)

Так уменьшается количество потенциальных использований.

Хотя анализ времени жизни может кушать много времени сборки

А вот это интересный вопрос. unique_ptr<T> означает, что либо T плохо перемещается, либо T& полиморфный; плохо перемещаются большие объекты и объекты с неконтролируемыми ссылками, полиморфные возвраты обычно существенно рантаймовы и завязаны на ввод. Если я ничего не упускаю, то в случае неконтролируемых обратных ссылок нас уже ничего не спасёт, а в остальных (большой или данные для типа читались в рантайме) объект потенциально-асинхронный и логика с лямбдами для него роднее?