[Bug libstdc++/111351] constexpr std::string objects permitted to escape constant evaluation when SSO

["foom at fuhm dot net" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351

--- Comment #4 from James Y Knight <foom at fuhm dot net> ---
vector and string are different in one key way: a zero-sized vector has no
accessible storage, while a zero-sized string has 1 byte of readable storage --
the NUL terminator. Because of that, I don't think it's unreasonable for a
zero-length vector to be constinit'able, while a zero-length string is not.

But, certainly the _more_ concerning issue is with non-zero-sized strings where
the validity of the program depends on what exact SSO size was chosen by the
implementation.

> libc++'s choice is confusing even for the experts, who have to maintain its split-brain SSO logic forever because Hyrum's Law

"Hyrum's Law" is exactly why I think it's a mistake to permit SSO-allocated
strings. It makes the SSO length a critical part of the interface. People will
start writing code which assumes that a constexpr global string of size "N"
works, and that will cause problems for other standard libraries which use a
different SSO size "M", if M < N. E.g. if libc++ starts allowing this, then
people who first target libc++ will find that strings up to 22 characters work,
and be surprised/annoyed by libstdc++ failing to build their program.

It is much simpler to say to users "you cannot make a constexpr std::string
unless it lives fully within constant-evaluation-time." then to also add "...OR
unless the size is short enough, where that size depends on your
implementation."