It’s Time for New C++ Leadership(brycelelbach.github.io)
brycelelbach.github.io
It’s Time for New C++ Leadership
https://brycelelbach.github.io/cpp_convenor/
2 comments
> it would be much better for someone to just fork the language
Great idea! They could call their new language "Rust", sounds like a pretty cool name all-around.
Great idea! They could call their new language "Rust", sounds like a pretty cool name all-around.
In this post, there seemingly a lot of focus on process, infrastructure (for the committee) and ideological issues. Instead, I would love to see a focus on technical competency, speed, and addressing customer requirements (for developers and companies).
well, as Nvidia C++ chief he certainly excels in those requirements also. plus, he's a funny folk. listen to his podcast.
C++ needs a major reboot. Remove old school annoying guys which hold all progress. Allow ABI break. Pick top 3 priorities and adress them in 2-3 years.
"Allow ABI break" is equivalent to "kill C++". Some people would like that. I would not.
A less drastic alternative is today allowed: define a new ABI, and see who joins you. This would be akin to what happened when we got the amd64 ABI, or the hybrid 32/64 x86 ABI (more registers, but pointers are still 32 bits): a different compilation target that also runs on the same physical hardware. OSes and linkers would need to recognize binaries compiled to this ABI, and take care not to mix them up.
People who want a new ABI do not like this model because they are not confident anybody would join them. That is itself reason enough not to accept ABI-breakage.
A less drastic alternative is today allowed: define a new ABI, and see who joins you. This would be akin to what happened when we got the amd64 ABI, or the hybrid 32/64 x86 ABI (more registers, but pointers are still 32 bits): a different compilation target that also runs on the same physical hardware. OSes and linkers would need to recognize binaries compiled to this ABI, and take care not to mix them up.
People who want a new ABI do not like this model because they are not confident anybody would join them. That is itself reason enough not to accept ABI-breakage.
Why not define the old ABI, and require either special tooling options or #pragma directives to access it. This is something that implementers could do on their own, with no need for any support by the Standard.
That's actually the problem compared to a conservstive language standard committe as in C (WG14). WG21 (C++) are the yea sayers, WG14 (C) the no sayers. C++ moves much too fast to please anyone. C is a glacier, and if they adopt something it's a mistake, or just bikeshedding.
ABI's have their own committee, the gABI. This is frozen.
ABI's have their own committee, the gABI. This is frozen.
I really don’t think design-by-committee is a good method to create a language. There’s a significant gap between spec writers, compiler developers, and end users when it comes to C++. I think this can be alleviated if the language designers work closely with the compiler devs as one team, while listening to user pain points directly - which is why I think Rust had success in a relatively short amount of time.