А почему разыменование end() строки - UB? https://en.cppreference.com/w/cpp/string/basic_string/end Ведь есть гарантии: 1) контейнер

непрерывен
2) str[str.size()] == CharT{}

http://eel.is/c++draft/basic.string#string.iterators-2 а чего вы ожидаете от past-the-end значения?

Дело в том, что past-the-end для std::basic_string не является past-the-end для underlying character array, начиная с C++11

тем не менее str.at(str.size()) бросит out-of-range имхо 2 было костылем для совместимости с С-строками, который решили не тянуть дальше

"В С++11 ввели" == "Решили не тянуть дальше"?)

не нашел нашел только это http://eel.is/c++draft/strings#basic.string.general-3.sentence-1

вы не поняли в С++11 унифицировали поведение operator [] для string и char * "не тянуть дальше" - остальные методы, аналогов которых нет у char *, решили не трогать

Поскольку "A specialization of basic_­string is a contiguous container", упомянутый Вами пункт фактически является гарантией валидности past-the-end

вектор тоже у него тоже теперь валидный past-the-end?

Для вектора [data(), data() + size()) is a valid range

обратите внимание, что это полуоткрытый интервал

[ )

Да, а для строки - [ ], в отличие от вектора

я понимаю идею, и теоретически стандарт можно было бы так трактовать, но в отсутствие The library never assumes that past-the-end values are dereferenceable. рекомендую еще поискать в LWG issues

Может чтобы в будущем сделать c_str deprecated/optional? Например для того же u8string c_str не имеет смысла, ведь нет C api которые могут работать с char8_t.

И в чем профит?

Целый байт экономим и ещё минус код который этот байт всегда дописывает.

никто там байт не дописывает

null terminated важное свойство, если и делать строку без сишной совместимости, то лучше новый тип - std::text

чтобы читать из потока как раз алиасинг нужен, иначе придётся конвертировать через memcpy

Не, мне вот кажется у меня и в тех проектах где работал, не так много кода, который опирался бы на cstring. В идеале я бы сделал опцию std либы, которая делает строку не c string + std::cstring которая совместима, пофиксил бы те места которые опираются на null terminated/заюзал std::cstring и жил бы с нормальными строками счастливо

А сильно нужен этот байт с такими изменениями?

Ну смотря кому, если смотреть доклад про fbstring, там они пытались писать байт только в c_str, ну и там был какой то код с нетривиальным датарейсом, в итоге сделали чтобы всегда был null terminated и потеряли пару процентов

Ну они могли бы и свою не с строку запилить

Ну там drop and replacement std::string на тот момент было

Aliasing это только если сериализовать через memcpy. Обычно таки бинарные протоколы сериализации это всяческие теги, битики, байтики отдельные.