Допустима ли такая оптимизация в реализации std :: string?

Я как раз думал о реализации std :: string :: substr . Он возвращает новый объект std :: string , который мне кажется немного расточительным. Почему бы не вернуть объект, который ссылается на содержимое исходной строки и может быть неявно назначен std :: string ? Этакая ленивая оценка фактического копирования. Такой класс мог бы выглядеть примерно так:

template <class Ch, class Tr, class A>
class string_ref {
public:
    // not important yet, but *looks* like basic_string's for the most part

private:
    const basic_string<Ch, Tr, A> &s_;
    const size_type pos_;
    const size_type len_;    
};

Открытый интерфейс этого класса имитировал бы все операции, доступные только для чтения, реального std :: string , поэтому использование было бы бесшовным. std :: string может иметь новый конструктор, который принимает string_ref , чтобы пользователь никогда не был мудрее. В тот момент, когда вы пытаетесь «сохранить» результат, вы в конечном итоге создаете копию, поэтому никаких реальных проблем с ссылкой, указывающей на данные, с последующим изменением их за спиной.

Идея заключается в том, что этот код выглядит следующим образом:

std::string s1 = "hello world";
std::string s2 = "world";
if(s1.substr(6) == s2) {
    std::cout << "match!" << std::endl;
}

будет создано не более 2 std :: string объектов. Это похоже на полезную оптимизацию для кода, который выполняет множество операций со строками. Конечно, это относится не только к std :: string , но для любого типа, который может возвращать подмножество своего содержимого.

Насколько я знаю, никакие реализации этого не делают.

Я полагаю, что суть вопроса такова:

Учитывая класс, который может быть неявно преобразован на std :: string по мере необходимости, будет ли соответствовать стандарту для писателя библиотеки изменение прототипа члена на возвращаемый тип? Или, в более общем плане, имеют ли разработчики библиотеки свободу действий для возврата «прокси-объектов» вместо обычных объектов в таких случаях в качестве оптимизации?

Мне кажется, что это недопустимо и что прототипы должны точно соответствовать. Учитывая, что вы не можете перегрузить только по типу возвращаемого значения, это не оставит места для авторов библиотек, чтобы воспользоваться этими типами ситуаций. Как я уже сказал, я думаю, что ответ отрицательный, но я решил, что спрошу :-).