C++26: more constexpr in the core language

The problem is that with the new wind C++ got with C++11, its role in GCC and LLVM, and domains like HPC, HFT, GPGPU, WG21 got up to 300 something members, everyone wanting to leave their name on a C++ standard, many proposing features in PDF form only.

And since in ISO driven languages, what gets into a standard, does so by votes, not technical implementation merit, it is about doing a proper campaign to get the bases to vote for your feature, while being persistent enough to keep the process going. Some features have more than 20 revisions on their proposal.

When I was in college in the 90s, templates were new and had iffy support. In the 2000s, STL was still problematic. I remember the Microsoft Compiler spitting out error messages on STL types that were so long the compiler couldn’t handle the string length and truncated the error message so you couldn’t see what the problem was. In the late 00s and early 10s I worked in games, we wanted stability and for the code to be as non-tricky as possible (for example by banning use of exceptions, STL containers, and most casual heap allocation, among other things.) So we used older compilers by choice. My current job publishes an SDK and APIs that people have been using for many years, they need to be backward compatible and we can’t impose recent language features on our users because not everyone uses them, we have to stick to features that compile everywhere, so I still see lots of C++{11,14,17}.

uniform function call syntax and a `restrict` mechanism have not made it in to the standard after so many years

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.

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

That is more a dynamic monkey patching programming language kind of thing.

At no point were lambdas single return statement. You might be confusing it with some other language feature. Or language.

The "STL" part of the standard library - containers especially but not just that - has an outdated interface, and suffers from ABI being stuck:

https://cor3ntin.github.io/posts/abi/

so it's embarrassing regardless.

> there still is no language support for e.g. debugging constexpr, or printing internal private state of objects in 3rd party code.

Actually, reflection might make it easier to do that. Supposedly, you should be able to get a member pointer to the private member you're interested in (or even do it dynamically by iterating over all members, and figuring out which one you like), from that and an actual object obtain a regular pointer, and finally dereference it.

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

    #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);
    }

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

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.

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.