Reflection for C++26

By ”stagnation” do you mean “not getting new features”?

N3340 is from 2011. Prior to c++11 they had failed to deliver major changes to the language. And arguably the disfunction is still there where big ideas get destroyed in committee (reflection) or take forever and come out half-baked (modules).

C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy.

So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. The issue is that those are the same features everyone has been asking for for over a decade so the people that really care found workarounds and eventually move over to the new std way of doing things when they can while everyone else continues waiting for that one feature they really care about.

Speaking of half-baked, did continuations get fixed?

The people complaining and the people asking for features need not be overlapping sets.

> the people that really care found workarounds

Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for.

> They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with.

I never got this. Can't you just decide to use subset of the language? No-one forces people to use every single feature. It's okay to use C++ like "C with classes" and occasionally cool new thing, when it is right tool for the job. Only people where this argument is truly valid are compiler/tools people.

I think the bureaucratic cadence of the things also make C++ not a unified entity. C++ is patchwork language. So many of the new features don't work well together or don't fit together or they have conflicting goals.

Since the proposals target problems with differing philosophies, they each have different traps in them from bad time complexity to outright unrefined behavior. Keeping up with the updates hard because of this.

I think many C++ projects are (or will be) basically infeasible to maintain not because of the old problems but due to the exploding complexity of the interactions of all features, unless developers actively ban using large parts of the language.

> Can't you just decide to use subset of the language?

No, you can't. Not in the long run, at least. You will have to use libraries that have chosen a different subset, new people will join your team, things will get sloppy as the company grows, etc. Committing to a subset of the language is not free, it's hard and it's a lot of work. And for what?

Also that the features c++ is getting are bolt on additions that we already have solutions for. I think fmt is a great example - fmt is a header only library that can be dropped in. Meanwhile std format was standardised without printing to stout. That took 3 years to standardise. Meanwhile we’re working on things like ranges, and instead of implementing them in the language it’s shoe horned in as a library feature - we now pay massive compile time hits for these features that are being shoved in alongside the kitchen sink. Meanwhile the solution (modules) has been talked about longer than I’ve been writing c++, it’s still unusable, and it hasn’t shown one of the key things people have been begging for for a decade - faster compile times.

I think the committee is focused on the wrong things

Not really. Even parts of the standard library (e.g. std::variant) more or less require the use of quite advanced language features.

>instead of implementing them in the language it’s shoe horned in as a library feature

Quite the opposite. Proliferating the language itself with ad-hoc constructs would be shoe-horning.

Personally I'd rather the comitte take longer and require more implementation experience before accepting new features. There are still too many half-baked ideas that turn out to be mistakes afterwards, resulting in either needless breaking changes or being stuck with bad solutions.

This is especially true for library features where users can always use third party libraries for containers/algorithms that are yet to be standardized (or indifinitely - not everything should be added to the stdlib). But even language features can and should exist as compiler extensions before we are stuck with them.

> There are still too many half-baked ideas that turn out to be mistakes afterwards (...)

Care to point an example?

Failed library features at least can be relatively easily deprecated, forgotten and left to rot on the side. Language features will bloat the language almost forever.

One nice advantage of static reflection, macros and other form of program synthesis is that you can experiment with new syntax as a library before committing to integrating it to the base language.

> Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for.

Some use cases like GUI programming sound like they are better addressed by specialized tech stacks. Nevertheless, either you're talking about greenfield projects or you are hard pressed to find a justification to rewrite a project in another framework. Claiming you stopped writing C++ doesn't fit the bulk of the experience of anyone maintaining C++ projects.

Some examples on top of my mind:

- export templates is the canonical one.

- Universal references are a great feature in principle, but the way they are integrated in the language is far from ideal.

- Both features are great in isolation, but the interaction between initializer lists and aggregate initialization is a giant footgun.

- Coroutines are overly complex and still incomplete but I still have hope.

- Modules feel DOA so far.

- Unrestricted compile time evaluation is great, but the constexpr qualifier per se doesn't guarantee any useful property.

edit: overall I'm happy with the evolution of the language, but the standardization process has flaws

marshall cline's c++ mini-faq is a list of about 100 pages of them from the 01990s

or people who need to maintain someone else's code, debug their own, write a library someone else might use, or understand compiler error messages, all of which involve understanding language features you don't yourself use (at least intentionally)

Partly true.

If you're writing library code that someone else might use, you don't have much need to understand the features you don't use, unless you have to handle them at the interface. If you're debugging your own code, you really shouldn't have to understand features that you didn't use. (Mostly - see the next paragraph.)

You did say "intentionally". You could wind up using a feature unintentionally, but it's not very common, because most of the new features are either in a new library (which you have to explicitly call), or a new syntax. There are definitely exceptions - I could easily see you using a move constructor without meaning to.

Maintaining someone else's code... yeah. You have to understand whatever they used, whether or not it made any sense for them to use.

i accidentally used the new implicit constructors for aggregates in c++ the other day, and then my code didn't compile with the version of clang i have installed on my cellphone

> Can't you just decide to use subset of the language?

That is harder than it sounds. First you have to select which subset to use, it is almost impossible to get any two engineers to agree on that - if you do get agreement that is a bad sign - generally it means the people in the room don't know C++ well enough to make the decision and so you choose the wrong one. The best you can hope for is a compromise where nobody is happy - and thus everyone will look for an excuse to bring in their pet part of C++ not in the subset because there is a "good reason" for an exception.

Even if you select a subset it is almost impossible to enforce whatever subset because even if you don't allow your people to use it directly odds are you bring in a third party library that does use it (the C++ standard library being the big one!)

There are a few exceptions to the above. No exceptions/no RTTI are commonly disabled exceptions and so you will get some compiler and library support. Game companies commonly write their own standard library. Both of these are done for performance reasons and have specific domain specific reasons that can be validated in a profiler to set their rules.

Not related to reflection, but C++26 is also likely to get profiles which will disable specific old constructs, (new/delete) which are proven to be error prone and thus result in security issues. These are a good subset to use, but it is about security and so mostly doesn't get the types of subsets you are talking about.

My experience maintaining old codebases is that you are just as hard-pressed to find a justification to write code to use new language features, or even to take the time to upgrade the language and compiler version. Most often you just continue writing code in the same style as the rest of the code base using an old version of the language and runtime.

Wish C++ fixed some of its mistakes in the standard library. std::regex is embarrassing when even Python can beat it and nobody uses std::unordered_map due to its pointer chasing. Basic Maps are something that you shouldn't need to use a third party library for.

Could you explain the issue with unordered_map?

The standard guarantees that you can get a pointer to an object in the map and this pointer will remain valid after rehashing and insertion/deletion of other elements. That basically forces implementers to use “buckets with linked lists”, also known as separate chaining. This is not cache friendly (and also suffers from excessive allocation). Other hash map implementations like abseil's don't provide this guarantee so they can put everything right there inline, which is much more efficient.

You can't have faster compile times. If you want fast compile times C++ needs to sacrifice something else (ABI compatibility, compatibility to compile code from 1979 for some dead big endian 12-bit word chip, etc.

In fact the truth is the people working on C++ don't actually value fast compile times over other matters (fast runtime, ABI compatibility, etc.)

They say they do. But they don't in their actions.

One egregious example: look at the compilation speeds of clang with release build configs (-O2 or higher, etc.) over the years.

It compiles much slower now than it did in 2014 for the same code. The compilation speed is worsening at a much faster rate than the runtime speeds are improving from version to version.

LOL. What used to be a typo is now becoming valid syntax (and of course the compiler can't warn you because it's now valid). Ouch. At least an old compiler saved you...

Ha! Modules. I wrote a basic version of that in 2006 for Boost. This is as big a useless mess as web components. It feels like c++ is in the legacy category with x86, still here, tolerable due to exponential efforts, and still dying for simpler solutions that aren't beholden to decades-old design mistakes. (variable instruction width, context-sensitive grammar, #include model, etc).

Services get split up and some parts rewritten. The parts are often written in new languages.

For 1 person, sure. The larger the team, or the more teams involved, this drops from easy to completely impossible.

I disagree completely. Libraries like ranges are dumped into algorithm, and are de-facto considered parts of the language. Reflection has gone back to have range support added, for example. Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated equivalent to me writing it myself. I would much rather gcc saw me passing a span around and could treat it as a special built in type.

I agree with you. I would move heaven and earth for faster unoptimizrd builds, but I’m perfectly happy with multi hour O2 builds from clang. The state that modules was standardised in proved what you’re saying - there were many opportunities to allow for faster compile times but instead we chose maximum flexibility with no consideration for what that leaves on the table.

> My experience maintaining old codebases is that you are just as hard-pressed to find a justification to write code to use new language features, or even to take the time to upgrade the language and compiler version.

That's perfectly fine. You should only pay for what you use.

Your average project, however, consumes dependencies and needs to keep them updated. Just because the code you write doesn't use them that doesn't mean your dependencies don't. So everyone still benefits with each release of C++ even if the are not using fancy features.

> marshall cline's c++ mini-faq (...)

Published in 1994.

Literally 30 years ago, years before there was even anything resembling a C++ standard.

I'm not sure why you thought it's relevant.

Personally I think this is true. C++ is multi paradigm and can be effectively used with many different subsets of the language and those subsets still interact well.

However that opinion is kind of a minority. There are a lot of people in the community who don't want to have to learn new features just because a dependency happens to use/expose them. I don't personally see the issue with it.

I'd rather learn std features any day over non-std features. It's just a better use of my time because they work everywhere and someday I might need them. However again not everyone shares this opinion.

You can still enforce a style guide and limit certain constructs via code review.

Plenty of the modern C++ people already do this by enforcing things like "no raw loops", "no raw pointers", or "no raw synchronization primitives" during code review.

The issue is that it's a lot harder to justify avoiding new features than it is to justify avoiding old features unless you have a tooling specific reason (ex lack of support) to do so.

Tbh this is why you need to set the C++ std version when you compile. Don't just assume the default for the compiler but hard lock it at a specific version so you can know which compilers you can support and compilers can warn you if you use new features.

> C++ is patchwork language. So many of the new features don't work well together or don't fit together or they have conflicting goals.

I don't really see this as true. In my experience most C++ features actually "just work" together and there are relatively few footguns involved in mixing features.

And it's less that C++ is a patchwork language and more that it is multi-paradigm and multi-discipline. Some features have specific applications and they get used inappropriately but in my experience that is solved with a quick reference/citation of the standard during code review or in a new ticket.

>Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated equivalent to me writing it myself.

False. Nothing prevents compilers from giving their own stdlib types special treatment under the hood.

> during code review.

There is the problem - code reviews are done by humans and so it is really easy to read some code and not think "wait this is new code it can't do that anymore". I read a lot of old code as part of my job and it often isn't worth the bother to update working code to new standards.

> it's a lot harder to justify avoiding new features than it is to justify avoiding old features

The problem is the opposite - people keep using old features when the new is better. I realize not everything new is better, but most of them are, yet people keep refusing to learn and use the new thing without good justification.

That would be an ABI break which is just not happening, and you know it. As it is we’ve decided it’s more important to be able to use std span from libc++ on clang than it is to have an optimised version for people on their tool chain.

> The problem is the opposite - people keep using old features when the new is better. I realize not everything new is better, but most of them are, yet people keep refusing to learn and use the new thing without good justification.

I think we are saying the same thing here. Often the new is better so it's hard to really justify sticking to the old outside of project specific reasons (i.e. toolchain doesn't support new std). That people do it has less to do with justification and more to do with time commitment or laziness and the excuses given tend to fall away once pressed.

i set it to c++20 on purpose, i just didn't know the feature existed (and didn't know that my clang didn't support that feature; i'm a little uncertain as to whether my clang is an outdated version without full c++20 support, or whether gcc is implementing a proposed extension that didn't actually make it in)

So you're saying that turning std::span from a standard library class into a language feature wouldn't break the ABI? How so? How would such a language construct fit into the existing ABI?

(for context: parent is referring to the fact that x64 calling conventions mandate structs larger than 64 bits to be passed in memory, which means that passing a 128bit std::span is going to be less efficient than passing a separate 64bit index and 64bit length, as those can go into registers)

it was actually originally published in 01991 (at which point it was just the comp.lang.c++ faq), but cline continuously updated the faq-lite until 02012†; see the update history at https://web.archive.org/web/20140225204048/http://www.parash.... so it's entirely your choice to only look at a version of it from 01994; you can easily find him merrily celebrating c++'s boneheaded design errors continuously after c++98, after c++03, and indeed after c++11, although the document was looking increasingly old-fashioned

however, even if we only consider the 01994 version, i still extensively disagree with your comment, and i will explain why in detail

in fact c++ was already well defined before ansi formed their committee in 01990, four years before the version of that faq that you chose to read. the arm (not the arm arm, the annotated reference manual) was the standard standard until c++98, and it's written as one. it says things like

> The following rule limits the context sensitivity of the rewrite rules for inline functions and for class member declarations in general. A class-name or a typedef-name or the name of the constant used in a type name may not be redefined in a class declaration after being used in the class declaration, nor may a name that is not a class-name or a typedef-name be redefined to a class-name or a typedef-name in a class declaration after being used in the class declaration. For example,

(that's from §9.9 if you want context)

but why would it be relevant whether there was a c++ standard or not? it would be relevant if the problems documented in the 01994 version of the faq-lite had been eliminated by standardization. but that is comprehensively not the case. every single one of the misconceived features in the 01994 version of the faq-lite is still in everything resembling a c++ standard, so all the pitfalls of poorly interacting features it documents are still relevant today. that's why i think that even the 01994 version of the faq-lite is relevant

so from my point of view it is not only wholly false to say that there was nothing resembling a c++ standard in 01994, it is also irrelevant whether there was anything resembling a c++ standard when the faq-lite was written (at least for 01994 and later versions)

furthermore, your particular choice of 01994 is unjustifiable and evidently only serves to provide a spurious veneer of justification for your irrelevant objection that (interpreting you generously) the faq-lite predates the c++98 standard. if you thought that was important you should have picked a version of the faq-lite from 01999 to criticize

______

† after a hiatus, since 02019, it is again being updated at https://www.parashift.com/c++-faq-lite/ but obviously the new center of gravity for this kind of thing is stack overflow and cppreference

Yeah, I think gcc has a std c++20 mode as well as a with extensions mode. And adding `-pedantic` helps because it forces extensions (unless specified in the std type) and non-conformant code to be rejected.

And that clang likely just didn't have full c++20 support. Which tbf I actually don't think any clang has full c++20 support currently as even bleeding edge clang still is missing a few things in the lang and library departments.

Yes that's right, what I meant was that for many of the use cases on greenfield projects that I used to use C++ for, I no longer do.

That sacrifice is called C++20 modules and quite alright on VC++ and clang 18.

Module are already being used by Office, and those of us that don't need to rely on GCC, don't hate CMake, can already enjoy using them.

Which is what I have been using on my C++ hobby projects for the last two years, on work projects we are still on C++17 land anyway.

No, the cat’s out of the bag with span (and unique pointer) now, we can’t go back. We knew this was a problem from unique_ptr and had an opportunity to not make the same mistake again, but instead we chose back compat for a new feature over something novel and performant

I think that what we have standardised as modules give us a path off the include model, honestly. It’s just that it’s the most pandered-to version of modules you could imagine. We entirely changed the compilation model and didn’t manage to tie module names to filesystem paths, meaning you need to parse the module file to figure out what module it is. It’s death by a thousand cuts

What is the issue exactly? Span is trivially copyable and destructible and, at least with the Itanium ABI, it can be passed (and returned) via registers: https://gcc.godbolt.org/z/4rbcshve4 .

Other ABIs might have different constraints but there is no reason why they couldn't special case std::span. In fact if span was a built-in type there is nothing preventing a compiler form picking a suboptimal ABI and being stuck with it. In any case it is not a standardization issue, but purely a QoI.

Yes, GCC can pass it in two registers. On the other hand Microsoft's x64 ABI doesn't:

>Structs and unions of size 8, 16, 32, or 64 bits, and __m64 types, are passed as if they were integers of the same size. Structs or unions of other sizes are passed as a pointer to memory allocated by the caller.

https://learn.microsoft.com/en-us/cpp/build/x64-calling-conv...

The parent commenter handled the ABI question for me, but I want to respond to :

> In any case it is not a standardization issue, but purely a QoI.

This is an enormous problem in the C++ ecosystem - playing hot-potato with whose fault it is, instead of trying to actually fix it. Span is a decent example, the standards committee get to say it's a vendor issue, and the vendors get to say that their hands are tied by the ABI. The result is that people spend time arguing about who should fix it rather than actually fixing it.

That's all well and good, but what would you do exaclty? The standard comitee cannot impose an ABI as it would be ignored by implementors. Implementors either own the ABI (MS for example) and are responsible for their owns screwups or there are other bodies that are responsible (the informal forum for the inter-vendor Itanium ABI for another example).

In any case this has nothing to do with std::span being an technically a library type or a built in. There is really no fundamental difference between the two.

For example std::complex and std::initializer_list have special handling on many compilers, just to mention two types.

> That's all well and good, but what would you do exaclty?

Start with having the standards committee accept that they are in fact where the buck stops, and that the language includes, whether they like it or not, the toolchain. They don't have to decide upon the toolchain, but their current MO of "toolchain/ABI issue == not our problem (except for when we decide we're not willing to make any backwards incompatible ABI changes, but only sometimes)." The vendors are already jumping through hoops to support what is being standardised (modules being the perfect example here).

I can't speak for std.complex as I've never had to use it, but I think initializer list would be a great example of "how much better would this be if it was special cased into the compiler". The benefit we would get from initialisation being consistent with the compiler far outweighs the benefit of being able to use libc++'s initialiser list with clang.

> There is really no fundamental difference between the two.

Except there is. If I write an implementation of the standard library, and provide an implementation of std span as (abbreviated) - https://gcc.godbolt.org/z/c1sz4neKG it's got to respect the various conventions instead of being treated as an opaque type (like a slice in go). If it's a `_Span`, the compiler is free to go "ok you're using this thing that I know all the internals of, and can reason about. I can elide bounds checks that don't pass muster, I can specify that I will generate code for this specific type that puts extent and data as registers in the following cases". But instead, on x64 (where I work 99% of the time so it's where my effort/knowledge is, sorry), we're bound by >64 == memory.

Now, you might call that a QOI issue, but I'd call it a design flaw that could have avoided an implementation issue, that we see on many features.

> except for when we decide we're not willing to make any backwards incompatible ABI changes

That's not an exception. The committee is not willing because the implementors explicitly said it is not going to happen, no matter how much Google cries.

> Except there is. If I write an implementation of the standard library, and provide an implementation of std span

if you write it as an user you are constrained by the ABI. But implementors are not: they can bless their own span with superpowers if they want to (in practice they would use special attributes). And there is no reason the compiler can't have builtin knowledge of the semantics of std::span (the same way it has knowledge of printf, malloc and the various math functions for example).

> But instead, on x64 (where I work 99% of the time so it's where my effort/knowledge is, sorry), we're bound by >64 == memory.

[Note this is an MSVC-specific ABI issue not a general x64 one. GCC uses the Itanium ABI on x64]

But the MSVC issue is really a red herring: there is a-priori no reason to expect they would have picked a better ABI for a built-in _Span. The committee cannot force compilers to be optimal (it can't even force conformance).

(Note I'm not singling out MSVC, GCC also has multiple less than ideal ABI decisions).

> The committee is not willing because the implementors explicitly said it is not going to happen,

Yeah, and I think this is the problem at the root of my gripe. If the committee was willing to reach this point earlier I think we’d be better off!

> But implementors are not: they can bless their own span with superpowers if they want to

Except that they don’t. And we can go around in circles here - I maintain this is a design issue, and it should be fixed at the design stage, rather than passed on to the compiler vendor who are stuck behind the theoretical design that pretends an ABI doesn’t exist, and their customers who will not upgrade if they break the ABI.

Lastly, I agree that the committee cannot force conformance or optimality, nor should they. But their unwillingness to accept that unless it’s technically impossible, the vendors will move mountains for conformance. This leaves us fighting with each other over who is to blame (see this thread), and in my opinion the end result is a half baked outcome that solves the paper problem but doesn’t solve the actual users wants.

>> But implementors are not: they can bless their own span with superpowers if they want to > Except that they don’t. And we can go around in circles here

Except they do. Look at GCC code for std::complex compared to the equivalent hand rolled class: https://gcc.godbolt.org/z/nqcvhPWex . edit: note that in this case GCC is just silly with the hand rolled one, but it does show that they are treated differently.

GCC does similar things with span where the class has special annotations for reference tracking to improve warning messages.

Library vs builtin is an implementation issue, not a standardization one. But yes, we are going in circle.