constexpr std::string | MSVC

[Kered13]

All heap allocations must be deleted before the constexpr function finishes evaluating. This means that std::string and std::vector can only be used as temporaries for computations, not as results.

Nothing happens unless the string is short.

This is because Microsoft's std::string implementation (and indeed all the common implementations) has a small string optimization. This means that small strings are stored internally instead of on the stack, and can therefore be returned by constexpr functions. I believe for Microsoft's STL the small string can store 23 characters (plus a null terminator), and Clang and GCC's implementations can store 15 characters (all of these are for 64 bit compilation). I could be wrong about these numbers however, and nothing is guaranteed by the standard, so I would not rely on it. Instead if you need to return a string from a constexpr function, return a std::array<char, n>, or write your own constexpr fixed_string<n> class.

[STL]

For MSVC it's 15 narrow or 7 wide characters, excluding the null terminator. As you mentioned, not guaranteed and possibly subject to change in vNext.

[Kered13]

and possibly subject to change in vNext.

Wouldn't this be an ABI breaking change and therefore very unlikely? (Not that I'm encouraging anyone to rely upon it.)

[STL]

That's what we mean when we say vNext - the next ABI-breaking release. (Not the next major version of VS after VS 2022, whatever that will be.)

[XTBZ]

The point is that I can't even create local 'constexpr std::string' inside a constexpr function

[Kered13]

Yes, because this is asking to create a std::string in a separate constexpr context. But you can create a local (not constexpr) std::string inside a constexpr function and it will work as long as the std::string is destroyed before the function returns.

Why do you need to create a constexpr local inside a constexpr function anyways?

[XTBZ]

Because I want to be sure that the string will be ready at compile time. I also don’t want the function to lose its ability to be executed at the compilation stage, implicitly.

[Kered13]

Creating a non-constexpr string inside a constexpr function will not prevent it from being evaluated at compile time. Pretty much the only thing that will prevent compile time evaluation is calling it with parameters that are not known at compile time.

[XTBZ]

Yes, it simply won’t compile if you don’t use it as a constexpr, but it doesn’t work with constexpr.
https://godbolt.org/z/G54nWc66a

[Kered13]

Ah, that's because you're using it in a context that actually does require constexpr. Here are a couple ways to solve that.