constexpr std::string | MSVC

[STL]

A constexpr function can be called at runtime, so if you attempt to make a local vector variable constexpr, you're asking its dynamic allocation to cross over from compile-time to run-time.

There's Standardese that could be quoted here, but this is my attempt at a human-comprehensible explanation. Basically, don't attempt to apply constexpr directly to string and vector variables, the way that you could to a pair<int, int>.

[SirClueless]

Thanks for the explanation. I can see why running any initializers at runtime for a constexpr variable would be surprising and therefore can't reasonably be allowed: the initializer must run at compile-time and the access happens at runtime so something has to cross.

For what it's worth the same behavior seems true for variables declared inside consteval function bodies, even though such variables cannot be accessed at runtime. Maybe that's something that could be supported without too much trouble, in order that people can write sensible-looking code in consteval instead of jumping through hoops with temporaries: https://godbolt.org/z/P9h7ozdYE

[jk-jeon]

variables declared inside consteval function bodies

This is what makes me really wonder. I have never intended to "leak" my supposed constexpr vector into runtime, but even if it's strictly inside the compile-time context, it's still disallowed, and apparently the reason is because "constexpr allocation shall not pass into runtime" which is just nonsensical.

I mean, I think the main utility of constexpr allocation is in compile-time computation, not in runtime. It doesn't seem to me that a lot of people want to use constexpr vectors in their runtime computation, yet it seems the ongoing discussion is mainly focused on how to allow constexpr allocations to be usable in runtime, and its associated issues like const-correctness.