https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351
Jiang An <de34 at live dot cn> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |de34 at live dot cn --- Comment #2 from Jiang An <de34 at live dot cn> --- > This will result in user code which can be built or not based on whether > their string happens to fit within the SSO string length. I find that quite > unfortunate, since it is supposed to be an internal implementation > detail/optimization, and this makes it effectively part of the API that code > will grow to depend on. This comes from the nature of SSO and constexpr variables. I don't think it worthwhile to revert this PR (https://github.com/microsoft/STL/pull/1735) for MSVC STL - which makes the codes harder to understand and slows down the compilation. > As comparison, libc++ rejects all the above examples, by forcing the SSO-size > to zero in constant evaluation context, so that a pointer to an external > allocation is always used. libc++ is, unfortunately, currently unable to implement constexpr SSO, IIUC. I failed to find a constexpr-compatible way to determine libc++'s std::string is in short mode if the short mode were enabled in constant evaluation. (As a result, libc++'s string always uses long mode during constant evaluation.) https://github.com/llvm/llvm-project/blob/0954dc3fb9214b994623f5306473de075f8e3593/libcxx/include/string#L829-L837 Note that there's no tag outside of the union, so we can't know which variant member is active without causing constant evaluation failure - unless the mechanism of std::is_within_lifetime (https://wg21.link/p2641r4) gets implemented.