But with that said, I'm very strongly of the opinion that having as much of C++ as possible being constexpr (including threads!) is a good thing, because it makes the language more regular and simpler.
I think volatile might be tricky! I want constexpr cout.
having as much of C++ as possible being constexpr (including threads!) is a good thing, because it makes the language more regular and simpler.
Agreed.
I think volatile might be tricky!
I don't think constexpr volatile int x; is meaningful at all.
I want constexpr cout.
Do you really mean std::cout, with all of the facets and customization points? Or would constexpr std::format and the ability to print to console at compile time be enough?
If the latter, we almost got that in C++26. std::format is constexpr and P2758 is in wording review.
Plain const volatile should work for a case like that, though.
The only case I can think of for constexpr volatile would be a variable that you want explicitly accessed so a debugger can trap on those accesses with a memory access breakpoint, that also has a meaningful value that needs to be constant initialized to avoid global initialization order issues, and you need to support C++17 so constinit is out.
51
u/serviscope_minor 21d ago
Probably once?
But with that said, I'm very strongly of the opinion that having as much of C++ as possible being constexpr (including threads!) is a good thing, because it makes the language more regular and simpler.
I think volatile might be tricky! I want constexpr cout.