> It’s too bad you still can’t cast a char to a uint8_t though in a constexpr expression.

Uh, what? That has worked fine since the introduction of constexpr in C++11.

This compiles in clang 21.1.2 with c++26.

    #include <cstdint>
    #include <print>

    constexpr uint8_t f(char ch) {
     return static_cast<uint8_t>(ch);
    }

    int main() {
     constexpr uint8_t r = f('a');
     std::print("{}", r);
    }

It would be cool, except for the entire language that is available at compile-time being C++, and thus entirely unsuitable for manipulating C++ programs.

Circle C++ does that

...isn't that what templates were made for? Template metaprogramming in C++ is Turing-complete.

This already exists with macros, templates, and compiler extensions, if you want completely unusable/unreadable code that takes forever to build.

The D language basically does that. You can write D programs that evaluate D code at compile time to generate strings of new D code which you can then basically compile-time eval into your code as needed. Combined with the extremely powerful compile-time reflection capabilities of D it's the closest thing I've seen to Lisp metaprogramming outside of that family of languages and it's easier to read than Rust macros or C++ template metaprogramming.

Maybe too far afield, but: https://leanprover-community.github.io/lean4-metaprogramming...

Gives what you wished for. It's functional, though (among other things). Unlike most lisps, (dependently) typed. But hey, available at compile-time.

> I'm actually looking forward to the related reflection features that I think are currently in scope for C++26.

The core of reflection should be in C++26, yes. In my understanding, there's more to do after that as well. We'll see when the final meeting is done.

COBOL is being actively developed as a language, the latest standard was published in 2023.

Although there are excellent alternatives to C++ such as Rust, C++ is still widely used as many open-source and commercial codebases are built with it.

Adding features to a language that is still actively used does not seem like a bad thing.

> Are they flogging a dead horse?

Not exactly. There's a lot of C++ code that still can't be rewritten into cool languages overnight without risking correctness, performance and readability.

I'm always happy to see C++ pushing itself and the compiler backends as it benefits the victims of lame codebases and also the cool kids using the improved compiler backends.

from which other language can I make a GUI with Qt while doing low-level graphics and DSP?

The resources here are amplified elsewhere.

As a specific example, expanding constexpr means a codebase I recently worked on can move away from template metaprogramming magic to something that is more idiomatic. That means iterating on that code will be easier, faster, and less error-prone. I've already done static dispatch using constexpr and type traits that would have taken longer to do with templates.

Currently constexpr programming needs you to know the specifics of what is supported - ideally you'll be able to infer that from first principles of the invariants that are available at compile time. That leads to faster, more confident development.

It's a similar story for reflection: we were using custom scripts and soon won't have to. The changes usually come out of the problems people are already finding solutions for in the real world, rather than gilding a lily.

Do you like using a fast web browser?

Maybe knowing where a language is going will help them implement older features? Also, some things are technically easy once all the conceptual wrinkles are ironed out. There is no reason some of these can't be added before C++20 is 100% supported.