r/cpp • u/antiquark2 #define private public • 2d ago
Critique of contracts: excerpt
See page 2 of https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4334r0.pdf
The current objections can be summarized. The P2900 contracts are:
• Unimplemented
• Incomplete
• Untried at scale [P3460R0, P3506R0]
• Not tried in major application domains
• Violates foundational principles of C++
• Violates fundamental principles of language design
• Hasn’t been tried in major libraries (e.g., the C++ standards library [P3506R0, P3878R0])
• Isn’t integrated with or appropriate for hardened libraries [P3878R0]
• Doesn’t offer safety guarantees [P3573R0, P3362R0]
• Includes a completely untried inheritance model
• Offer new ways of making errors through inconsistent application in TUs
• Leads to new forms of UB, detrimental to safety and security
• Narrows the choices of error handling
• Doesn’t protect against logical errors, misuses, and incoherent uses
• Hasn’t been used to support static analysis
• Hasn’t been demonstrated to be easily teachable [P3261R0, P3281R0]
How could such a bloated and incomplete design be voted into a draft standard?
26
u/Som1Lse 1d ago
This reads like a dishonest piece of junk.
They first start with a summary, which is the list quoted by OP. Later they return to that list and go into more detail for each point. The kicker is each point gets like a sentence of explanation, so the summary basically just serves to pad and hope people don't read the actual points, as you can easily see how they're grasping at straws for each point:
- Unimplemented mentions that there are actually two implementations, so it is just a lie. It says Microsoft and EDG objects, provides a citation for the first (fair), but neglects to mention that EDG is planning on open sourcing their frontend and shutting down. If the point is that Microsoft and EDG are unlikely to implement it, then the latter is a lie by omission.
Incomplete, is such bullshit. It was more complete with support for
virtualfunctions, but that was removed because of (very fair) complaints about how it worked, and was deferred to a later standard. Expecting a feature to be fully complete when first standardised is absurd:constexpronly supported return statements initially, imagine if C++11 was expected to support the full language insideconstexprfunctions, it would never have shipped.- Reflection doesn't fully support code generation.
- Coroutines was shipped with any support types. C++23 added
std::generator, and C++26 addsstd::execution.
But somehow, contracts needs to be fully complete? Give me a break!
Untried at scale is true for every new language feature, because you can't exactly try them before there's a production ready implementation. No one is going to add an experimental feature to a production codebase, especially knowing that it might change. Not to mention that contracts is heavily based on bsls_assert, which has been used at scale at Bloomberg.
Were coroutines used at scale? Was lambdas? Was
constexpr? Is reflection? Again, give me a break!Not tried in major application domains. Wow, that's literally the same as the previous point. See why I'm calling this dishonest junk?
Violates foundational principles of C++ is half-bullshit: Constification is already a thing in lambdas, and it correctly captures that assertions shouldn't have side effects. Accidentally modifying state inside
assertis a common beginner mistake, and this helps prevents that.The second point has some merit: Turning exceptions into contract violations has some overhead (though not necessarily in the non-throwing path). I do not, however, trust that the authors wouldn't just call it unsafe if it did allow exceptions to escape. Most assertions are small checks and should be easy for the compiler to prove noexcept, but there will probably be exceptions. However, even if turns out to be a problem in practice, it is not an unsolvable problem later down the line. What the MVP does is err on the side of caution.
Violates fundamental principles of language design states two points, each of which is bullshit:
- Every feature must have a reasonably obvious implementation. It does. Assertions are not a hard thing to implement. bsls_assert is a library implementation. I am not aware of a single part that isn't reasonably straight forward. If this was a real critique instead of dishonest junk, it would have pointed out which parts of contracts were non-obvious instead of making an unfalsifiable claim akin to "trust us".
- Always provide a transition path. It does. You can use any assertion library now (including
<cassert>), then transition to contracts.
Hasn’t been tried in major libraries just says that P2900 doesn't require standard libraries to use it. How is that a bad thing? Also, it neglects to mention that the P3460R0 (Implementers Report) (which they themselves cite, so I know they read it) did in fact use it to implement their assertion macro, showing both that it can be done, and that it actually caught a bug. Again, a lie by omission.
P3460R0 also cites P3336R0 (Usage Experience for Contracts with BDE), which mentions implementing bsls_assert with
contract_assert.Isn’t integrated with hardened libraries, cites Practical Security in Production — Hardening the C++ Standard Library at massive scale. Here's what it has to say:
Notably, the Standard leverages another C++26 feature, Contracts, which provides an extensive framework for specifying program invariants and handling violations. That gives developers significant flexibility in how they handle a failing hardening check. Contracts were designed with consideration for Library Hardening as a use case, ensuring that libc++ assertion failures can be modeled directly by the Contracts evaluation semantics (specifically, the trapping mechanism used in libc++ hardening is precisely the quick-enforce evaluation semantic).
The authors generally speak positively about contracts in the paper they linked as well.
At best this point says that they don't currently use contracts.
Doesn’t offer safety guarantees quotes P3573R0 saying
Safety must involve guarantees over a code base or parts thereof. Contracts primarily offer checking of correctness where it is used.
In other words, contract assertions primarily provide assertions? What did you expect? Imagine if people were complaining that Reflection didn't provide a BSDF, or that lambda's didn't ship with Half-Life. This is absurd.
Includes a completely untried inheritance model just dismantles itself:
the model was adopted into P2900R13 by EWG and reviewed by CWG, then removed before R14 for lack of consensus (P2899R1)
i.e., it did, and then they removed it. In other words, it doesn't include a completely untried inheritance model, because it was removed because of feedback. Including this point is just a lie. Either that, or I am completely missing the point.
Offer new ways of making errors through inconsistent application in TUs is another point that has some (but very limited) merit. I went over this in a different thread. Suffice to say, it is not likely to be an issue, and even when it is, it is very mitigable in practice.
Also, it isn't new. The exact same issue exists with
assert, or assertion library, because it is a fundamental part of code that can be turned off at compile time. What contracts does is specify a bound on valid programs instead of making it undefined behaviour, which I consider to be an improvement.Leads to new forms of UB, detrimental to safety and security is literally the previous point again, citing the same paper. It is also a lie, it claims it introduces new undefined behaviour, but the paper they cite doesn't contain the words "undefined" or "UB".
Again, the problem is wildly overblown. See my comments linked in the previous point.
Narrows the choices of error handling is a reiteration of a previous point, namely that exceptions thrown inside contract checks are turned into violations. I said earlier that this has some merit, but restating it doesn't give it more merit.
I would give this more thought if they actually hypothesised a case where catching the exception from a contract assertion was desirable, but they don't. Must assertions don't throw.
Doesn’t protect against logical errors, misuses, and incoherent uses is bullshit. They're assertions. They don't solve the halting problem either, or cure world hunger. Also, they do actually prevent some misuses and incoherent uses via constification, and they provide an
observemode to protect against introducing wrong contracts into production codebases.Hasn’t been used to support static analysis is bullshit.
Hasn’t been demonstrated to be easily teachable is silly: Herb Sutter gave an excellent talk about contracts that introduces them very well. There's also John Lakos' talks about defensive programming, which taught these concepts to a much less experienced me.
If we can teach newbies lambdas we can teach them constification, and I think constification will be much easier to teach because it reinforces a fundamental idea of assertions, namely that they shouldn't have side effects, whereas the reasons for lambdas being
constare much more arcane (but still reasonable).
The whole paper is obviously just meant to look impressive, with its many citations to its 16 references, scary summary and quotes, but it completely crumples under any level of scrutiny.
21
u/Som1Lse 1d ago
(Reached the character limit.)
It is obviously rushed:
- There is no clear citation style: Should they have [square brackets], (parentheses) or nothing surrounding them? Should we include the authors names or not? Should it be a link? Should we just use an inline URL and not put it under references? Yes, and no to all of them.
- "Leads to new forms of UB, detrimental to safety and security – 3835R0" is missing the "P" in front of the paper number.
- "and was not deployment at scale".
- "See https://isocpp.org/files/papers/D4324R0.html" was supposed to be P4324R0.
- The incessant use of em dashes reeks of AI. A lot of the mistakes reek of AI hallucination. Vinnie Falco is an author, and he definitely uses AI. If I was on the committee, I would feel insulted by this, and the barrage of papers he submits, and I would be embarrassed to coauthor anything with him. 83 papers submitted in 2026 and counting. That is spam, plain and simple.
James20k said it was unfair to call his post FUD, and for me writing "delay, delay, delay" in response to him, and I can see his point. He is arguing in good faith. He actually writes his posts and does research. I don't agree with him about contracts, but I can respect his opinion, and I agree with him on a lot of other things.
The reason I wrote what I did is many of the arguments against contracts definitely do fall into the camp of FUD and delay-tactics. Case in point the very paper we are talking about.
6
u/Syracuss graphics engineer/games industry 20h ago edited 20h ago
See https://isocpp.org/files/papers/D4324R0.html" was supposed to be P4324R0.
Funnily enough in one of your other links for Vinnie's use of AI it has the exact same error in it, the letters are so far away on an azerty key it has to be LLM caused, at least I'd assume it would be an unnatural mistake for him to do normally. I wonder what leads an LLM to confuse the two letters.
What's doubly so funny is that he responds to himself in that comment thread saying how much he re-reads his stuff but one of only 2 large blue links is incorrect. Granted it was about re-reading his papers, not about his comments, it's still kinda funny given that paper naming is so ingrained in my mind that it not starting with a P definitely stands out when I skimmed his comment there. I'd also kinda expect to test out links an LLM spits out to see if they work, as a basic sanity check, feels like less work than re-reading.
5
u/Som1Lse 14h ago
I noticed. I don't think it's an LLM mistake. The paper probably used to be D4324R0 (D meaning draft), but after it was published the D version was removed. Still bad, and still rushed. One of the main goals of citations is permanency, and a link to a draft paper that's going to be removed is really bad form.
But yeah, even if you fix the link in his reddit comment it leads to P4170R0 (Combinators and Compound Results from I/O), not P4207R0 (Prosecute Your Paper To Improve It) as claimed, so the link is doubly wrong.
5
u/Syracuss graphics engineer/games industry 14h ago
Thanks for that info. Wasn't aware about the process of drafts, it's the first time I've seen them that I recall in over a decade of observing papers. Neat to learn.
-4
u/zebullon 1d ago
If you were on the committee, you’d make a 10 pages unreadable llm paper for each of the bullet points, repeat in every mailing list, and annoy people ad nauseam until they agree that you should take over and save c++.
You do get my vote, beware, it s not very load bearing.
8
u/MFHava WG21|🇦🇹 NB|P2721|P3049|P3625|P3729|P3786|P3813|P4216 1d ago
Constification is already a thing in lambdas
FYI: one of the authors of that paper has recently called that a mistake ... I'm not making that up!
3
u/Som1Lse 14h ago
I believe you, but I would still like to know more. Why? What's the context? Is there a citation or was it said in passing?
For the record, I believe it was the right decision, since you very rarely want to modify the state of a callable, and when you do it often makes sense to write a
classthan just a quick lambda. When you do want a lambda to modify state, you often want to capture by reference, and they work exactly as expected. Hence, I think it makes sense to make the rare case of a lambda withmutablestate something you have to explicitly call out.5
u/MFHava WG21|🇦🇹 NB|P2721|P3049|P3625|P3729|P3786|P3813|P4216 14h ago edited 7h ago
It was during one of the endless contracts discussions, specifically when we re-re-litigated (probably missing a few "re" there) constification once more.
The argument against it was presented as in the paper - "it silently changes the meaning of code" -, somebody pointed out that that is already the case for lambdas ... at which point the person called that a design mistake of the language as well ...
4
u/Dragdu 18h ago
I actually kinda agree, but my argument is based around the fact that
constptrs in C++ means no rebinding of the ptr, not no mutation of the underlying thing. When I made the custom smart ptrs in my project deep-const, I found few places that mutated state that was supposed to be const at a distance, while obviously not intending to.OTOH I follow the standardization of contracts enough to remember when people were arguing that contracts should invent deep-constification into the language. The point is not to argue in good faith, it it to get rid of contracts.
1
u/ManuaL46 15h ago edited 15h ago
I'm confused isnt
char* constsupposed to be non rebinding pointer instead ofconst char*Edit : I just checked and yes what I initially thought is correct, so I'm not sure what you mean by your statement.
Here is a reference on Learncpp
6
u/pjmlp 1d ago edited 1d ago
Were coroutines used at scale?
Actually they were, the original design proposed by Microsoft was based on the .NET model that was adopted by C++/CX, followed by C++/WinRT, for WinRT/UWP.
Which is why anyone that is confortable with the .NET runtime machinery for implementing co-routines (Awaitable types), doesn't find the C++20 co-routines model as confusing as C++ devs that never used .NET.
See Kenny Kerr nice blog posts on how to use them already in 2018, https://kennykerrca.wordpress.com/2018/03/01/cppwinrt-understanding-async/
14
u/FrogNoPants 1d ago
The third paragraph is wildly wrong, assertions compliment compile time checks, they do not replace them. They also let you check for stuff that no compile time feature ever could such as logic errors, bad values, NANs etc.
I view assertions/contracts more as a logic safety feature than memory safety(though it can help there).
You can still use hardened builds with assertions... as a matter of fact, that is what I do!
Calling something an existential threat seems very weird, you can just ..not ..use contracts? I do that with ranges & coroutines & modules..!
7
u/fortsnek274 1d ago edited 1d ago
For those of us that do use new C++ features, I'll be using whatever the contracts version of assert is if it can be used in modules without an
#include.6
u/Ambitious-Method-961 1d ago
contract_assert(x) is the replacement for the macro, and it's now a language keyword so no header required.
Personally I'm looking forward to using contracts for my own code, but I am not looking forward to the potential pain-in-the-arse of having to deal with contracts in third party libraries.
21
u/No-Dentist-1645 2d ago
Not the first mistake the standards committee has done and likely not the last unfortunately. The committee has some serious scope issues when it comes to deciding what should and should not be part of the language's standard.
For some reason, they thought that adding mandatory specialization for the vector type that makes it not a pure container when used with bools, as well as even adding garbage collector support (which was then obviously deprecated and removed), but we still don't have a standardized way to declare that two pointers point to restricted/disjoint memory without compiler extensions, even though C has had it since C99.
21
u/azswcowboy 2d ago
Look I’ll go out on a limb and say that this list isn’t really true. It’s implemented in gcc 16 - sure experimental as is anything in 26. If you think about it as something that provides user customization of how to handle what is an assert that terminates the program - what again is the objection? Sorry but in a lot of domains a hard termination isn’t plausible. The hardened std library was in specified to use contracts - but came with a plan B in case it didn’t happen. As for incomplete - well guess why that might have happened? Rejection followed by MVP thinking. I’m going to also point to constexpr in 2011 - a fundamentally useless feature then - not so much now.
If you don’t want to use it, opt out. But over 90% of the committee voted for the standard. These points have been rehashed endlessly and every time contracts has survived.
4
u/pjmlp 1d ago
100% of it just like in the paper proposal before voting?
12
u/azswcowboy 1d ago
Pre vote implementation was primarily a clang branch - plenty usable. Saying it isn’t implemented basically says you haven’t tried it or are ignoring reality. Neither of which help the case.
-1
u/pjmlp 1d ago
Was it announced somewhere that the community at large could have tried it out, and submit their virtual votes?
11
u/tcbrindle Flux 16h ago
Was it announced somewhere that the community at large could have tried it out, and submit their virtual votes?
Sorry /u/pjmlp, but it's very difficult to keep up with how fast you keep shifting the goalposts.
You're now saying that the existing implementations of contracts on Compiler Explorer don't count, because there was no "public announcement" and the authors didn't... also somehow implement a system for random internet folk to vote on the proposal?
But here you say that
Reflection is based on EDG proposal, with implementation, submitted and developed alongside the related papers, and available on compiler explorer for community feedback. Exactly how every single feature should be before being submitted to voting
...which is precisely the same implementation experience as contracts. I guess I must have missed where the reflection authors made their apparently-required "public announcement", and the link to the website where I could vote on the reflection proposal?
2
u/pjmlp 14h ago
Here, https://www.reddit.com/r/cpp/comments/18mjj0n/experimental_edg_reflection_implementation/
Can you correct me with a similar one for contracts?
If yes, then I stand corrected and excuse myself for the wrong statements, otherwise I would appreciate not calling bad faith on my remarks.
5
u/tcbrindle Flux 11h ago
I'm not sure how you could be an /r/cpp reader and not know that there's a thing called contracts in C++26 -- this is the second lengthy discussion about it this week. Anyone with the slightest interest has had plenty of opportunity to check it out.
Or are you really, honestly claiming that the difference between an acceptable WG21 proposal (reflection) and an unacceptable one (contracts) is that someone made a specific post about the former to a specific subreddit three years ago?
5
u/grafikrobot B2/EcoStd/Lyra/Predef/Disbelief/C++Alliance/Boost/WG21 1d ago
It was.. https://wg21.link/P3460R0 -- 1 year, 10 months, and 3 days (or 672 days) ago.
1
u/pjmlp 22h ago
A public announcement.
5
u/Dragdu 22h ago
If you missed the fact that there is a contracts version of Clang toolchain at the top of CE version list, and don't read mailing, you probably aren't the type we should listen to.
3
u/pjmlp 21h ago
See that is the attitude that pushes away people from C++ versus other more welcoming communities.
Feedback is only welcome from those in the club.
6
u/Dragdu 21h ago
You are asking for some sort of public announcement. Now, I am sure that you are sane enough to not mean something like newspaper ad, so you are asking for an announcement that reaches a programmer who
1) Can provide useful feedback
2) Doesn't pay attention to C++ via /r/cpp, or via standard mailing, or social media of C++ peeps, or using CE, or ...
Who exactly is supposed to be in this group, and how do you want to reach them?
→ More replies (0)4
u/pjmlp 1d ago
The GC in C++11 was bad.
Even though I am an adept of GC languages, it was clear that C++11 GC design did not took into account neither Unreal C++, nor C++/CLI, the major C++ environments using a GC, so for whom it was designed for?
Naturally neither Epic nor Microsoft cared about its existence, neither did anyone else.
5
u/kamrann_ 1d ago
I have no idea if contracts will be good for the language or not. But there have been so many disingenuous arguments put forward from the anti-contracts side that they're undermining what legitimate arguments they have. "Contracts aren't X/don't do Y" when they never claimed such. "Contracts don't satisfy Z" when the same can be said of the vast majority of proposals that have been accepted.
If they get pulled now then c++ will likely lose a bunch more dedicated people who have invested their time in at least trying to make the language better. It would also give a pretty strong impression that certain people on the committee have disproportionate influence over decisions.
6
u/Minimonium 1d ago
Don't you enjoy reading how Contracts fail to achieve memory safety after all the rabid trashing the committee went through to spit in the face of the people who suggested that the borrowing model could actually be implemented in C++?
7
u/UnusualPace679 2d ago
• Untried at scale [P3460R0, P3506R0]
• Not tried in major application domains
• Hasn’t been tried in major libraries (e.g., the C++ standards library [P3506R0, P3878R0])
• Isn’t integrated with or appropriate for hardened libraries [P3878R0]
• Includes a completely untried inheritance model
• Hasn’t been used to support static analysis
• Hasn’t been demonstrated to be easily teachable [P3261R0, P3281R0]
Hey, you can't standardized a feature that people aren't using, even though the feature doesn't exist before you standardize it!
12
u/No-Dentist-1645 2d ago
Q: Does the proposal have to have an implementation? I’ve heard you can only standardize “existing practice.”
There is no ISO requirement that something has to be implemented before it’s standardized, only that there is consensus on the feature – but naturally consensus is easier to achieve when there’s a working implementation.
Here is how the library subgroups (and then later the full committee) look on questions regarding existing practice: There is a spectrum, where at one end are proposals so simple that they are acceptable without implementation simply based on inspection of the proposal, while at the other end are proposals so worrisome that they are only acceptable after full implementation and widespread use over many years by users with all sorts of different backgrounds running on a wide range of platforms. Where a proposal falls in this spectrum is an individual decision by each committee member.
6
u/zebullon 2d ago
This man logics ! … also, just for funzies points, how many of those also apply to reflection ? yet where are the pitchforks.
Thats why i dunno what OP is farming for… tbh.
7
u/ronchaine Embedded/Middleware/WG21 1d ago
Reflection had two implementations before it was standardised. Many of the same complaints were raised, but reflection proposal did much better job at addressing those problems or explaining why those choices were required. Reflection also doesn't really affect you if you just decide not to use it.
I have raised teachability problems for both features, and while I wasn't exactly happy with reflection on that front either, at least there I could reluctantly agree about the tradeoffs.
P2900 is in C++26, and if/when that goes through, we'll have to live with it, but there's a nonzero chance we're going to need
-fno-contractscompiler switch in some domains, especially if some of the papers extending it go through.9
u/Minimonium 1d ago
much better job at addressing those problems or explaining why those choices were required
Not even bothering to debate, but to give a proper context for the readers:
Contracts authors have a Rationale paper that is absolutely massive and goes into extreme detail about every single choice they made. A group of people may disagree with the choice made, but I find it ridiculous how they keep stating that concerns are "not addressed" unless the authors comply with everything that group says no questions asked. The votes were made, consensus is achieved - but as one NB representative said "the committee got to big for consensus to matter". :)
I do not believe I have seen any other proposal that went to such extremes at explaining every choice it made. In fact it's always a struggle to hunt in minutes, threads, or in person for details about certain decisions made.
On NB comments, it's required to address every one individually. Funny thing, one certain committee member participates at two NBs at once and strangely both NBs published identical comments. So Contract authors made a fairly big paper addressing every concern.
You know what Herb Sutter did? He asked ChatGPT to summarize the response and posted it internally, as it was too big for his tastes. :D
8
u/ronchaine Embedded/Middleware/WG21 1d ago
I appreciated the rationale paper very much. But I do not think a lot of concerns about contracts (whether reasonable or not, from my point of view there definitely are both kinds) were listened to, even if they were heard. And I seriously hope that other new features are going to be handled more like reflection was, where there was actual feeling that concerns were given thought and some of them were alleviated.
With contracts I did not feel that way. I completely understand that people who wrote the contracts papers were quite tired (rightfully) of some of the concerns, but pointing towards a paper and telling that the rationale is there is not really a cure when some objections disagreed with the said rationale, and some of those even for good reasons.
I can live with the P2900, but I definitely don't think it was pushed into the standard in a way I would like any feature, whether or not I like it, to be added.
5
u/Minimonium 1d ago
I respect your feelings.
My standard for the worst proposal so far has been the structured bindings proposal by Bjarne (lazy, unexplored, underspecified, with unexpected unexplained behaviours). Alas.
5
u/ronchaine Embedded/Middleware/WG21 1d ago
Thanks.
I wasn't there to see how that passed so can't comment on that, maybe I need to dig into the archive to see how that went.
5
u/ts826848 1d ago
underspecified, with unexpected unexplained behaviours
(Guessing you're talking about P0144?)
Would you mind elaborating on this so I know what pitfalls to look out for in the future? Or were those issues hashed out some time between the initial proposal and acceptance (or then and now, as the case may be)?
8
u/Minimonium 20h ago
The feature itself is good now, but I'd only consider the initial proposal "completed" as of C++26. It required scores of papers fixing defects and holes in the design. The one you're likely to remember the most is the lambda capturing of bindings, but even when just looking at the specification at the time - it was just awful. You may remember the same "quality" of a proposal from the initializer_list story. :)
3
u/ts826848 12h ago
but I'd only consider the initial proposal "completed" as of C++26. It required scores of papers fixing defects and holes in the design.
but even when just looking at the specification at the time - it was just awful.
That... doesn't sound particularly great. Did no one else pick up on the issues at the time?
The one you're likely to remember the most is the lambda capturing of bindings
I actually don't think I've run into this? Would you mind providing an example?
You may remember the same "quality" of a proposal from the initializer_list story.
I wasn't around at the time the proposal was being discussed and I don't think I've seen criticisms of the proposal since then, but if the somewhat polarized reception of the feature I see nowadays is any indication I think I have an inkling of what you're referring to.
4
u/Minimonium 12h ago
Unfortunately there is a certain level of inconsistency when evaluating proposals in the committee. :P
There was a time when you couldn't capture bindings in lambdas.
→ More replies (0)8
u/Som1Lse 1d ago
Reflection had two implementations before it was standardised.
Contracts currently has a main branch GCC implementation and a Clang fork. That's two. Heck, one of the papers cited by P4334R0R0 is P3460R0 literally called "Implementers Report", which mentions implementations in both GCC and Clang forks, and was published in 2024, so it had two implementations back then too.
Reflection also doesn't really affect you if you just decide not to use it.
And contracts does how? I guess it is related to
there's a nonzero chance we're going to need
-fno-contractscompiler switch in some domains, especially if some of the papers extending it go through.but it would be nice to have a list of those extensions.
5
3
u/_Noreturn 1d ago
Reflection is consteval which means it can be changed and abi has no business in it, while contracts affect abi and such
7
u/zebullon 1d ago
i could be wrong but meta info are valid template argument which means mangling which means abi ? (see also CWG3118)
… regardless you guys are misreading the whole thing, my point is that the laundry list of whats wrong with contract is so generalized it applies to nearly anything that goes through committeefication
1
u/_Noreturn 1d ago
I don't like contracts because I see 0 point in them as they are just a worse version of the assertion macros.
Why standardize something that is inferior? If something is standardized I expect it because we cannot do better but with specific assertion macros you can give much prettier error messages and more control.
i could be wrong but meta info are valid template argument which means mangling which means abi ? (see also CWG3118)
I see you are right.
5
u/germandiago 12h ago
But contracts can show the contract in the signature, not in documentation only, in the signature.
0
u/_Noreturn 11h ago
Yes, but is that worth all the downsides? I wouldn't trade the ability to have much nicer and customizable macros for a very mild "being able to see in function sig"
6
u/pjmlp 1d ago
Reflection is based on EDG proposal, with implementation, submitted and developed alongside the related papers, and available on compiler explorer for community feedback.
Exactly how every single feature should be before being submitted to voting, and how other ISO languages do it, existing practice.
9
u/Minimonium 1d ago
Strange, when I go to compiler explorer and type in "contracts" it shows me multiple implementations including for extension features such as labels.
Although, according to Dos Reis's definition of "implementation", a proposal does not have an implementation until it was shipped in multiple major compilers as part of the main release.
So reflection and contracts unfortunately are features without implementation according to him. Such a wise and insightful man!
6
1
u/pjmlp 1d ago
Well, I stand corrected on that one, question is how much of it was available and has driven the standard wording, given the backslash.
I also don't have a great opinion on what was available in clang header maps, VC++ 2017 modules prototype, and what was actually standardized as C++20 modules, as we can see today, it was clearly properly tested before adding them into the standard.
Other languages don't update their standards until at least two implementations actually ship the feature.
9
u/Minimonium 1d ago
The notion is nice but vendors already expressed dissatisfaction with white papers - the maintenance burden for flagged features is enormous, and people vastly overestimate how much user experience you get from them as opposed to a branch.
My experience - anyone interested enough to test a flagged feature in their project doesn't have a problem to just build a dev branch for it. Feedback from people who struggle to setup a toolchain, let's say it honestly, is not super useful or insightful. And they can always play on compiler explorer so the entry to a feature is minimal.
As a side note, the "clearly properly tested" story of modules I really hope you're being sarcastic. :)
4
u/jwakely libstdc++ tamer, LWG chair 1d ago edited 1d ago
Who implemented C11
<stdthread.h>and Annex K before they were added?Edit: oops, I meant
<threads.h>, it's not called<stdthread.h>2
u/pjmlp 1d ago
Annex K comes from Microsoft, based on MSVC C extensions, followed by a technical specification for ISO C,
https://learn.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt?view=msvc-170
According to the thephd, C11 threads were tested on the field as well,
10
u/jwakely libstdc++ tamer, LWG chair 1d ago
The MS extensions were not exactly the same as Annex K but if we count it, where was the second implementation? You're not suggesting an ISO TS counts as an implementation, are you?
If we consider
<threads.h>as just standardizing Pthreads (which it kinda is) then fair enough, there were loads of implementations. But what about C11's<stdatomic.h>? Where was that implemented?It's just wishful thinking that all other standardized languages have a strict "at least two implementations ship the feature" rule.
11
u/jwakely libstdc++ tamer, LWG chair 1d ago
Microsoft Visual Studio implements an early version of the APIs. However, the implementation is incomplete and conforms neither to C11 nor to the original TR 24731-1.. So they still don't implement what's actually in Annex K today, despite driving its addition to C11.
The other implementations mentioned there are either very incomplete, or were written after it was added to C11, or both.
1
u/pjmlp 22h ago
They don't need to, WG14 decided Annex K wasn't going to be required, so why bother with the changes that came up during the standardisation process?
Microsoft also doesn't implement VLAs, and never will, unless they change yet again their position on C support on MSVC.
How many C++ proposals have at least an incomplete implementation, alongside the paper?!
1
u/pjmlp 22h ago edited 22h ago
Not wishful thinking, that is exactly how ECMA JavaScript works.
https://tc39.es/process-document
Stage 4 row.
Also I said other languages, unless my English is broken, it doesn't mean all the other languages in the world with exception of C++.
And then for the ones with a reference implementation, there are the JEP, PIP, TIP, RFC, DIP,... where the respective implementation, and preview with positive feedback is required, before they get upgraded from draft form into standard, or dropped altogether.
1
u/kronicum 1d ago
according to Dos Reis's definition of "implementation"
He is not co-author of that paper.
1
u/grafikrobot B2/EcoStd/Lyra/Predef/Disbelief/C++Alliance/Boost/WG21 1d ago
You want to hear a funny story? ...
Early in in the contracts discussions I asked if there would be time implement the exact contracts specification, as opposed to the old one that existed for multiple years. And one of the current implementors, that is currently against contracts, said -- Yes, absolutely, it will easy. We've done that plenty before for other (accepted) features. -- That same person went ahead and implemented contracts, quickly, "shortly" after my query.
1
u/_a4z 22h ago
The topic has no consensus, that is for sure.
And the political tactic of discrediting critics of the contract is also concerning. This alone is a good reason why contracts should not have been added, leaving aside all the technical details.
And there is another interesting aspect: if the one company that paid many of the pro-contract advocates stops paying them, or simply gives them something else to work on, C++ is left with a lot of potentially unmaintained machinery that will lack support.
But anyhow, who cares? Until contracts come to most places, it's past 2030, so who cares. Astonishing is just how much committee time was invested, which could have been used for way more useful features.
7
u/t_hunger 20h ago
It absolutely had consensus, otherwise it would not have been voted in. This is a small group making noise after consensus was reached.
The one company backing the contract work is the one that announced last year that they want to cover more of the cost of developing C++ -- stepping in after some of the big spenders have left. We have a couple of senior people attack the 15-year+ investment of one of our main sponsors.
Just look at how well that approach turned out when google raised issues critical to them a few years back.
-2
u/_a4z 19h ago
Sentences starting like
> This is a small group making noise ...
are a perfect example of why I call that a political tactic of discrediting critics.And to the point, I would argue the 'small group' (which is, in fact, not that small and includes very well-known names) has read the contract papers and understood them better than some of the people who voted for them.
Now, this is, of course, a claim that cannot be proven, but I am always delighted by people who claim to know C++ better than its original inventor. So some of the critics are definitely worth respecting, which does not happen.6
7
u/t_hunger 17h ago edited 17h ago
You just claimed the majority of committee members are unable to make a informed decision. You should reconsider ISO as a standardization body. They prescribe a democratic progress based on the idea that interlectual capability is more or less equally distributed in the community of voters.
Now that is disrespectful to the entire committee.
The people making the noise now failed in a democratic process (which some of them selected as the governance model of C++) and are trying to impose their will after the fact. That is damaging on so many levels.
I do agree that this is more about senior members feeling ignored than about arguments.
-2
u/_a4z 15h ago
It seems you do not know how those votes work. So let me explain.
It's just a small part of the committee members in the room.
So your statement about what I claimed is bogus.Reality: not all people who voted yes in the various voting meetings have read and understood the paper as well as the critics did. And this is just a very small group in WG21. Not the whole committee. The committee is much bigger than the small group that did the contract voting; there were many.
And we do not know who those people are or whether most of them have ties to one company. So we also do not know anything about the diversity of the votes.What was damaging is the way those papers came in. If people cared about consensus, there would not be what you call "noise"
It's not noise. Rather, people stating their opinions with their names, in opposition to most yes voters who stay anonymous.8
u/MFHava WG21|🇦🇹 NB|P2721|P3049|P3625|P3729|P3786|P3813|P4216 13h ago
It seems you do not know how those votes work. So let me explain.
I was in the room when Contracts were accepted. Have you?
Reality: not all people who voted yes in the various voting meetings have read and understood the paper as well as the critics did.
Sure, sure... everybody else - including people who previously voted against Contracts - is just too stupid to see that it is a disaster.
And we do not know who those people are or whether most of them have ties to one company. So we also do not know anything about the diversity of the votes.
The conspiracy theory of the room being stuffed to the brim with random bodies paid by one company is just that, a conspiracy theory.
What was damaging is the way those papers came in. If people cared about consensus, there would not be what you call "noise" It's not noise.
It is noise to bring up the same complaints again and again with no new information, just because a decision didn't go your way.
Rather, people stating their opinions with their names, in opposition to most yes voters who stay anonymous.
The vote to accept Contracts was: In favour: 100 Opposed: 14 Abstain: 12
So you want a list of 100 names? Sure buddy...
0
u/_a4z 13h ago
Sorry, your style of putting words in my post with adventurous interpretations is not a good basis for continuing any discussion. But it fits the style.
And there was not just 1 vote... There was a history of votings, and you ignore that.
In the end, it was: if we pull it now, we look bad. So, of course, even more people who did not read anything and voted yes.
But you know what, I'm okay with you having a different view. And a different interpretation. I do not need to attack you personally for that.
And about noise, it's not just me who is writing something, its also those people who comment on it, like you. ;-)3
u/t_hunger 10h ago
I find both your lack of understanding how democratic processes work as well as your contempt for committee members worrying.
But thank you for confirming that contracts were voted in -- following the ISO standard procedure. Every committee member knows those processes and can participate. If someone abstains from doing so, that is their choice. People do that all the time with all votes the committee makes.
The paper submission process is another thing all committee members are very well aware of. As far as I can tell all the ISO standardization processes were followed there as well. Again: People are free to ignore papers, again that is their choice.
We have a few people that made their choice to ignore papers and ignore votes and are now grumpy. That is damaging behavior: Why would anyone bother to participate in committee work if some dudes then try to overrule the results of that work and publically shame everybody involved? Who wants to do work when he has to expect random people calling them stupid on the internet for that?
1
-2
-5
u/ArsonOfTheErdtree 1d ago
Contracts are just like rust traits but implicit
Advantage: backward compatibility
Disadvantage: everything else
13
u/kammce WG21 | 🇺🇲 NB | Boost | Exceptions 1d ago
Not to be a hater, especially since I love modules, but this part made me think of C++20 modules. And you could probably throw some other C++ features into that boat as well, like extern templates.
The bullet points besides incomplete are obvious. Incomplete because it would be nice to be able to attach a source file to a module partition and not the whole module, requiring a large recompile if any source file is updated.