Will std::string end up being our compile-time string after all?

[admin]

Many developers and library authors have been struggling with compile-time strings for quite a few years now - as the standard (library) string,

std::string

, requires dynamic memory allocation, and isn't constexpr.

So we have a bunch of questions and blog posts about how to get compile-time strings right:

<ul>
<li><a href="https://stackoverflow.com/questions...strings-in-c?r=SearchResults&amp;s=1|175.4358">Conveniently Declaring Compile-Time Strings in C++</a></li>
<li><a href="https://stackoverflow.com/questions...compile-time?r=SearchResults&amp;s=2|100.5015">Concatenate compile-time strings in a template at compile time?</a></li>
<li><a href="https://stackoverflow.com/questions...-manipulation?r=SearchResults&amp;s=4|91.3811">C++ Compile-Time string manipulation</a></li>
<li>(off-site) <a href="https://crazycpp.wordpress.com/2014/10/17/compile-time-strings-with-constexpr/" rel="noreferrer">Compile-time strings with constexpr</a> </li>
</ul>

We've now learned that not only is

new

available in

constexpr

code, allowing for dynamical allocation at compile-time, but, in fact, <a href="https://herbsutter.com/2019/07/20/trip-report-summer-iso-c-standards-meeting-cologne/" rel="noreferrer">

std::string

will become constexpr in C++20</a> (C++ standard working group meeting report by Herb Sutter).

Does that mean that for C++20-and-up code we should chuck all of those nifty compile-time string implementations and just always go with

std::string

?

If not - when would we do so, and when would we stick to what's possible today (other than backwards-compatible code of course)?

<hr>

<sub>Note: I'm not talking about strings whose contents is part of their type, i.e. <em>not</em> talking about the equivalent of

std::integral_constant

; that's definitely not going to be

std::string

.</sub>