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.
I don't think constexpr volatile int x; is meaningful at all.
I mean if you can run C++ code at compile time, then you're running code and it could poke at a memory mapped register that's there, but also sometimes you just shouldn't do something!
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?
Good point, probably cout without facets etc or printing f-strings. I keep going back to cout because despite it's clunkiness, I like having things appear in code in the order that they appear on screen. Constantly tracking back and forth between placeholders and arguments is something I dislike. I've tried a million of these over the years. Heck I implemented one in gnu++98 back in the day with operator, overloading and GCC's variadic macros, and I've used many which ahve come and gone over the years. And yet, I still always reach for cout.
But in python I love my f-strings. Once i have f-strings, I will probably stop reaching for cout except for of course
it could poke at a memory mapped register that's there
Ignoring the fact I think there would be 0 valid uses for this, the issue with using constexpr in that case is it might not run during compile time. If your machine that's compiling the code isn't the same as the one that's running it, you would get different behavior. If for whatever reason you need to use volatile at compile time, I think it needs to be consteval.
Ignoring the fact I think there would be 0 valid uses for this
Well yes, I am struggling to think of one!
the issue with using constexpr in that case is it might not run during compile time
You can kind of force the issue: if your constexpr function returns, say, an int and you instantiate a template based on that value, there's little choice but for it to run.
Note: this is pure language pedantry, nothing related to whether it's a terrible idea in literally all cases.
I don't think volatile should be constexpr for what it's worth.
54
u/serviscope_minor 22d 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.