you are viewing a single comment's thread
view the rest of the comments
[–] 5 points 1 week ago (4 children)

What this means is:

WG21, what we usually call "the C++ committee" is the working group that prepares the C++ draft to the actual ISO committee, that is SC22, that approves the standard.

In WG21, people vote (or poll, really) as individual experts, who are members of one national board or an another. WG21 decided to send a draft to SC22 with knowledge that multiple national bodies (NBs) would object, it wasn't exactly a secret to anyone.

Then, in the ratification of the actual standard, it is NBs from different countries that actually vote. These are usually the same people who take part in WG21 work, though NBs can decide by themselves how they choose their vote.

In my national board, majority was against, with zero objections, so our NB chose to be one of the 9 countries who voted against. I do not know how other national boards work out their vote, but AFAIK most of them also have internal vote for that. This is how international standards committees are supposed to work, as to not have any country or entity push a standard that doesn't have clear consensus. There are varying opinions if that suits programming language development or not, and I'm not interested in that debate.

For the standard to be ratified, it needs both 2/3s majority in favour, and no more than 1/4th objecting. Now the SC22 vote failed on both counts, which pretty much means there isn't going to be C++26. We don't have time in the committee to get it approved in 2026 anymore.

I have my own thoughts about why we went from "zero objections ever" to failing both requirements. And even if I was part of the objecting votes, I hardly consider the result of having disapproved ballot a good outcome. It shouldn't have ever gotten to the point where that was even an option.

  • source
  • hideshow 4 child comments
  • [–] 2 points 1 week ago* (last edited 1 week ago) (3 children)

    This makes me wonder what we're the arguments against, is there a read about why NBs were opposed?

    Edit: Found an answer by Harald Achitz in comments to the post, but that's a lot to read, it seems:

    it's not just one paper, but rather a whole book. Thats the problem.

    As an entry point, I recommend:

    Procedural problems: P4381 (https://wg21.link/P4381)

    Technical problems: P4334 (https://wg21.link/P4334)

    Both papers reference plenty of other papers, so they provide a good starting point for getting an overview.

    This blog series by Mateusz Pusz also provides an excellent overview of the topic: https://train-it.eu/blog/series/cpp26-contracts/

    My personal favorite topics, the problems for binary package management and the growing number of implementation-defined aspects introduced by contracts are actually not covered exhaustively by any of these sources. (imho) The response to the technical concerns about build systems and package management was essentially: Nothing new here. The situation is already a mess, so we're just adding more mess. Literally!

  • source
  • parent
  • hideshow 3 child comments
  • [–] -2 points 1 week ago (1 child)

    p4334

    The P2900 contracts and extensions aim to change the nature of C++ and are an existential threat to C++, adding complexity and bloat (~56 pages in the draft standard for an incomplete version), potential overheads, and novel opportunities for errors without addressing the current community and regulatory body demands for guarantees (e.g., https://docbox.etsi.org/CYBER/CYBER/Open/ETSI_TS_104_198_DRAFT.zip presents C++ as providing no memory safety guarantees).

    (emphasis mine)

    Honestly I think this is by far the largest mistake that has led to the current C++ situation: listening to things like the corporate Rust party line and the Rust community (who also have the unveiled interest of replacing GPL-like code and licenses with corporate-friendly ones that allows wealth to steal projects from skill, see eg.: Ubuntu), instead of examining what's on the field, what's on the mind, and accepting that the way C++ functions is intrinsically different than a language that only provides you the tools to let you do what the makers want to let you do. Because the truth is, C++ does provide memory safety guarantees, it just puts them at a lower level of mandate than the mandate that you can make the code do (mostly) what you want rather than only what the Party line allows.

    Not to mention, in this day and age anyone who surrenders to Trumpism and its associated modern Mc-Carthyism-like demands is ethically too compromised to be trustable in a field.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 1 week ago* (last edited 1 week ago)

    anyone who surrenders to Trumpism and its associated modern Mc-Carthyism-like demands

    I didn't catch this part, how is that related to the topic? Edit: or how it relates to the rest of your post

  • source
  • parent