I always like these new comile time features getting into the C++ spec.
I'm actually looking forward to the related reflection features that I think are currently in scope for C++26. I've run into a number of places where the combination of reflection and constexpr could be really valuable... the current workarounds often involving macros, runtime tricks, or both.
Recent C++ changes seem like polishing your firewood before burning it. Yes, they make perfect sense, but often they are a fix to a problem that committee introduced by cutting down previous proposals (e.g. forcing lambdas to be single return statement, then relaxing it).
Half of new features feel like "how to make STL implementation less embarassing".
Meanwhile there still is no language support for e.g. debugging constexpr, or printing internal private state of objects in 3rd party code.
It would be cool to have the entire language and runtime available at compile-time like in Lisp
every release adding more constexpr stuff honestly helps me - been burned by old template hacks enough lol. you think we ever get to a real point where all this new power just makes stuff easier, or is it always tradeoffs?
That’s super cool; c++ is always the sharpest tool in the drawer (and by virtue the funnest!)..
It’s too bad you still can’t cast a char to a uint8_t though in a constexpr expression.
[dead]
Are they flogging a dead horse?
C++ is, should be, like COBOL. A very important language because of the installed base. But why the continual enhancements? Surely there are better uses of all those resources?
Anyone else getting concerned about the rate of development of the C++ Standard vs compiler implementation? We don't even have feature complete C++20 on the major compilers yet. C++23 is even less implemented. How will the committee handle this? Will they reduce feature additions at some point in the future?
https://en.cppreference.com/w/cpp/compiler_support