For the first time, a C++ standard failed to pass the national bodies
26 points by mond
26 points by mond
There are, roughly, three camps:
By far the largest group is the last one. I was in the third category, but using Verus in Rust has moved me to the second: I actually do want contracts, but not ones that look anything like P2900. Verus is the killer app for Rust (or something like Verus: there are a few things in this space and some of the others look potentially more promising). Rust vs C++ in systems programming has a bunch of complex tradeoffs. Rust + Verus vs C++ is not even worth a discussion, it's such a clear win on the Rust side that C++ isn't even worth considering. With P2900, C++ has explicitly ceded that space in perpetuity.
The big structural problem with C++ is that most (probably. At least many) features are there with a large majority in the 'don't care' camp. For the good things there's a broad consensus that the thing is desirable and a smaller group with the expertise to build it. Atomics are a good example of this: memory models are really hard. At a guess, at least 90% of WG21 (including me!) are not competent to design an atomic memory model (fortunately, it was there before I joined, though some refinements are in flight). But everyone agreed that being able to write a mutex in pure C++ was actually pretty important and kind-of embarrassing for a systems language that you couldn't. Lambdas are simpler because they are not new in the abstract machine: C++ already had objects that overloaded the call-as-function operator so most WG21 members understood the necessary compiler transform to add them as syntactic sugar and understood why they're desirable.
There are a lot of other things that go in because some small group thinks they're very important and no one else cares. I think these show a flaw in the process. These things should be in Boost or other well-supported external libraries. They don't need to be in the standard library. I believe the standard library should be:
A lot of current and proposed things fit none of these categories.
Below this, the language should provide two categories of things:
The former should be driven by standard-library and external requirements based on experience. C++11's r-value references are a nice example here: You can't implement smart pointers that can be safely added without them. There are a few other things that would be very nice to add here (borrowing semantics and viewpoint adaptation would be top of my list, non-local return from constrained lambdas would be near the top) for similar reasons.
The latter should be driven by large scale deployment experience. When people are frequently repeating the same pattern, provide syntactic sugar. Again, lambdas are a great example here. They do not add any new abstract-machine semantics. You can implement lambdas purely as a source-to-source transform that targets C++98. A lambda is a class with a constructor that takes its captures as arguments, fields that are copies of or references to its captures, and an operator() overload that takes its arguments. But typing all of that is annoying and lambdas make it easy.
P2900 added both things: new abstract-machine semantics (ODR violations that are not ODR violations, ways of running code before and after functions), though not quite enough to constrain contracts to be something you can reason about (defining a subset of the language for contracts was explicitly out of scope, which means contracts are just conditionally-executed code, not something that you can use usefully for any form of analysis). New syntactic sugar (pre, post, and contract_assert), where the pre- and post-condition syntax is a short form optimising for a specific use case (that every contract has an expression, rather than that contracts are things that you'd apply using reflection-like interfaces to particular API shapes, or want to describe one parameter, or parameter set, at a time) with no large-scale deployments of C++ contracts to motivate these choices (the largest deployments of contracts in other languages have a completely different design of contracts, which was explicitly ruled out of scope in P2900).
This has never been the policy for C++ and it does not have an analogous design philosophy against which things could be judged.
Importantly, it looks to me as though the committee just repeatedly ignored the comments/feedback of the national bodies throughout the process, and then ran face-first into a wall at the vote.
There is some confusion here because of what 'national body' means. I am a member of the BSI delegation to JTC1/SC22/WG21. The BSI position is that all of these representatives are serving in an individual capacity. I represent myself (and possibly my employer) in discussions around C++. My opinion and others go into a Draft International Standard (DIS). This is then voted on by the national body representatives to JTC1/SC22 (the 'Programming languages, their environments and system software interfaces' subcommittee of the 'Information technology' committee in ISO). When it's approved, it becomes an ISO International Standard (IS).
The BSI representatives to SC22 may or may not be members of WG21 (I actually don't know who they are and probably should). But their remit with the BSI is to represent the BSI in a context that extends to all programming languages and related things. Their remit is very different from WG21 members.
Normally, the national body representatives to SC22 just take whatever the working group agreed and present it because they trust these WGs. For the first time, various people have been actively talking to their (and other, which is probably against the rules) country's SC22 representatives and asking them to vote against the DIS.
I have numerous technical, cultural, and process objections to P2900 and don't think it should be included, but I also don't like the fact that SC22 was lobbied in this way. I don't think P2900 should have made it as far as it did. It isn't just a bad solution, it's a bad solution to the wrong problem.
There's a lot more in the article that I can't comment on without breaching the confidentiality agreements of various bits of this process. I agree WG21 has serious structural and process problems. I agree P2900 should not be in C++26 (and, ideally, nothing like it should be in C++29 - if we're going to do contracts, let's do them based on state of art for 2006, not state of the art for 1986). I agree that a lot of what's said by the contracts advocates has been disingenuous, misleading and, in some cases, outright false. I disagree that they are alone in that (there are two very vocal anti-contracts people who have been particularly bad in that). I agree that lobbying NBs is not the whole story for why the DIS failed and I think the fact that people engaged in it was a symptom of the problem, not anywhere near the root cause.
That Stroustrup photo is amazing
This has a lot more details than I expected, and I thought I already knew most of the discussion around the contracts
A different version of Contracts was up for debate around 2018, and was kicked out not too long after
And maybe they'll return again! Or has the process changed for the worse since 2018? From the quality of things standardized since c++17 I wouldn't be surprised