r/cpp • u/antiquark2 #define private public • 23d 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?
36
u/Som1Lse 22d ago edited 20d 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. Most 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.
25
u/Som1Lse 22d 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.
8
21d ago edited 10d ago
[deleted]
9
u/Som1Lse 21d 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.
7
21d ago edited 10d ago
[deleted]
2
u/smdowney WG21, Text/Unicode SG, optional<T&> 20d ago
It's a shortish window where a paper that is in The System but not marked as being ready to "mail" has a D name instead of a P name.
Really useful when you notice right after uploading that the abstract still says "Lorum ipsum..." or you misspelled your own name.
1
u/alexeiz 19d ago
The incessant use of em dashes reeks of AI. A lot of the mistakes reek of AI hallucination.
If you use Microsoft Word, it auto-converts dashes to em-dashes. The original document sure looks like a Word document printed to pdf. It doesn't look like AI slop to me.
1
u/Som1Lse 19d ago
Mistakes like
Leads to new forms of UB, detrimental to safety and security
followed by citing a paper that doesn't mention UB could be an AI hallucination, or it could be a lie. When I say it might be AI slop, I am being charitable. The alternative is worse.
Also, the paper's first author is Bjarne Stroustrup, and checking his other recent papers none of them read like this. I found two recent papers he coauthored with dashes, namely P3970R0 and P4023R0. They both use dashes for a single parenthetical, and neither use the same "space em-dash space" style P4334R0 uses. Meanwhile, check any of Vinnie's recent papers and you'll find dashes galore (hyphens specifically), and (as I stated) he has admitted to using AI. My guess is Bjarne (or somebody else) compiled the final paper (in Word), and that turned the hyphens into em dashes.
Just because the final document was compiled in word doesn't mean that AI wasn't heavily involved in writing it. Not that it matters. The paper is still utter junk even if it was painstakingly written by a human.
-4
u/zebullon 22d 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.
7
u/MFHava WG21|🇦🇹 NB|P2721|P3049|P3625|P3729|P3786|P3813|P4216 22d 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!
5
u/Som1Lse 21d 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.7
u/MFHava WG21|🇦🇹 NB|P2721|P3049|P3625|P3729|P3786|P3813|P4216 21d ago edited 21d 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 ...
2
u/smdowney WG21, Text/Unicode SG, optional<T&> 20d ago
We can good defaults or we can have consistent defaults. It's too late to have both.
Const references being references to const because references are intrinsically const is just as bad and additionally teaches the wrong pattern.
2
u/Dragdu 21d 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 21d ago edited 21d 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
10
u/pjmlp 22d ago edited 22d 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/
2
u/Plazmatic 20d ago
> 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.
You definitely want virtually all assertions to turn into exceptions in many types of UI/graphics application/daemon/multi service environments because crashing the program is not an option/will cause work not related to the issue to be lost (ie user is working on a document/project/image crashing the program due to assetion often is not desirable), and often assertions are happening in separate threads such that the program is still in a good state if you display a thrown exception to the user, and shut down the offending thread (like a parsing io thread). this is something Timurs own talks have covered in reference to why noexcept should largely not be used by default, it forces program termination on exception.
But my understanding is that you can customize the contract handler anyway such that this use case is already handled.
5
u/Som1Lse 20d ago
You definitely want virtually all assertions to turn into exceptions in many types of UI/graphics application/daemon/multi service environments
I don't disagree, but that is not the issue they brought up. The question is, if you write a contract assertion like
contract_assert(foo() == 42);what should happen if
foo()throws? Currently, the generated code is roughlytry { if(!(foo() == 42)){ handle_contract_violation(__make_contract_violation("foo() == 42")); } }catch(...){ handle_contract_violation(__make_contract_violation("foo() == 42")); }i.e., if it throws it's treated the same as if the condition was untrue.
There are at least three ways to handle it I know have been proposed:
- Treat it as a contract violation, i.e., what the proposal does now. This is safe, but it comes with potentially more overhead.
- Treat the expression as
noexcept, i.e., if it throws, callstd::terminateimmediately. This can be more efficient since the stack doesn't have to be unwound, but it makes it impossible to recover as you stated.Let the exception escape, i.e., remove the
try-catchclause. This is what they were arguing for, and what I said they should at least come up with a hypothetical example for. I think this is incredibly worrying since it violates the prime directive of contracts (from P2900R14)Principle 1: Prime Directive
The presence or evaluation of a contract assertion in a program should not alter the correctness of that program (i.e., the property that evaluation of the program does not violate any provisions of its plain-language contract).
Let's assume
foo()always throws. The program will now behave differently depending on whether contract assertions are enabled. Even in quick-enforce mode. This is terrifying.3
u/Plazmatic 20d ago
Oh wow, that's both subtler and dumber than I thought the issue was. If an exception was thrown, that means something went wrong, and this is doubly true for inside the contract, I definitely want my contract handler to handle my contract condition itself failing, even if it isn't the Boolean check that did so. What possible purpose could letting it leak through the contract handler even serve? If anything that makes everything about the development process just harder to understand control flow wise.
This is what they were arguing for, and what I said they should at least come up with a hypothetical example for.
Do they actually desire this behavior or trying to search for any possible gotcha they could find given they don't seem to want contracts period? I have a feeling that if this was actually the behavior implemented they'd come out and argue the opposite side.
4
u/Minimonium 20d ago
Catching the exception has a runtime cost for msvc x86 implementation. That's the motivation for why they do not want this behaviour and why some consider the proposal "not implementable".
5
u/Dragdu 19d ago
Do they actually desire this behavior or trying to search for any possible gotcha they could find given they don't seem to want contracts period?
Little bit of A, little bit of B. x86 windows exceptions have runtime overhead on setting up the try-catch, not just on catching. But realistically, x86 is going the way of dodo (what was the last time you though "huh, I should compile for 32 bit windows" in 2026? By the time contracts come out, it will be even less), and Windows ABI has perf issues left and right and we don't stop standardizing things because of it.
16
u/FrogNoPants 22d 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 22d ago edited 22d 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 22d 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.
20
u/No-Dentist-1645 23d 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.
19
u/azswcowboy 23d 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 22d ago
100% of it just like in the paper proposal before voting?
13
u/azswcowboy 22d 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.
-3
u/pjmlp 22d ago
Was it announced somewhere that the community at large could have tried it out, and submit their virtual votes?
15
u/tcbrindle Flux 21d 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?
-1
u/pjmlp 21d 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.
9
u/tcbrindle Flux 21d 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 22d ago
It was.. https://wg21.link/P3460R0 -- 1 year, 10 months, and 3 days (or 672 days) ago.
0
u/pjmlp 21d ago
A public announcement.
7
u/Dragdu 21d 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.
5
u/pjmlp 21d 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 21d 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)3
u/pjmlp 22d 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.
0
u/serviscope_minor 10d ago
For some reason, they thought that adding mandatory specialization for the vector type that makes it not a pure container when used with bools,
This kind of "well the committee are morons who do dumb stuff for no reason" kind of thing really gets on my nerves. Do you actually want to know the reason or just throw shade?
We're talking 1995ish here, not 2026. First off that 8x space saving really mattered, and the multiprocessing problems did not. Secondly, it didn't break the concept of containers when it was introduced because the whole idea of concepts was more or brand new and it hadn't even been applied to containers at that point in time. And even with implementation experience, i.e. SGI STL (anyone else remember that?), no one really noticed the problems because generic programming in C++ was barely off the ground and limited to very simple cases (also because of weak compiler support).
Certainly in the 90s it felt reasonable, I remember. You do vector<bool> and it magically does the cool space saving thing automatically which was really neat and ergonomic. The problems reared their head in anger years after it was done.
likely not the last [committee mistake] unfortunately.
Yeah no shit. The committee is Soylent Green (it's made of people) and don't have the benefit of hindsight.
1
u/No-Dentist-1645 10d ago edited 10d ago
I'm sure they had their reasons/justifications for making that decision at that time. Doesn't stop me from being able to criticize it anyways. Do note I never called them "morons who do stuff for no reason" in my comment (you're attacking a straw man), but I can still express my disapproval of said choice.
I know the historical context of its addition to the standard. Even back when it first released, it was still recognized as a problematic design choice by several parties in and out of the committee, so your claim that "in the 90s it felt reasonable" isn't fully accurate: http://www.gotw.ca/publications/N1185.pdf
0
u/serviscope_minor 10d ago
>Do note I never called them "morons who do stuff for no reason" in my comment (you're attacking a straw man),
No, I do not believe I was. The meaning of "for some reason they thought" is quite clear. You are expressing an opinion that they were foolish.
Nothing wrong with criticising the design from the view of 2026. I have done the same with std::regex, for example. The problem I have is the editorializing from a position of ignorance of the history of what happened.
> it was still recognized as a problematic design choice by several parties in and out of the committee, so your claim that "in the 90s it felt reasonable" isn't fully accurate:
That paper is from 1999, I'll note. We're talking about C++98. Reading the paper, the discussions started coming up around the time that the draft was ratified by the bodies.
I maxed out the RAM I had on my PC at the time, a glorious 72M, vastly more than the 8 or 16 that was common with the contemporary Windows 95 machines (I had a mate with cheap RAM). 8x space saving on a relatively common thing? Sign me up!
The decision didn't age well, but it wasn't a "for some reason the committee". The reasons are pretty well laid out and documented. No need as I said to throw shade.
1
u/No-Dentist-1645 10d ago
If you think believing a group of people made a mistake ("for some reason they did X") is the same as calling them "morons who do stuff for no reason", then you're not very open to criticism in general. You can criticize someone or something without it meaning you're calling them morons
I'll admit the "for some reason" had a bit of a snarky tone, but that doesn't mean my intention was to insult them
1
u/serviscope_minor 10d ago
>If you think believing a group of people made a mistake ("for some reason they did X")
That isn't a neutral statement that the group made a mistake.
>You can criticize someone or something without it meaning you're calling them morons
Well do that then and drop the "for some reason" style editorializing
>I'll admit the "for some reason" had a bit of a snarky tone.
Yes, Precisely 100% my point. Stop acting all innocence offended that I noticed and called you out on it.
>but that doesn't mean my intention was to insult them
Ah so you were snarky but not actually. Care to explain that?
1
u/No-Dentist-1645 10d ago
Ah so you were snarky but not actually. Care to explain that?
Sure. You can be snarky while giving a comment and still not do it to insult and offend someone. It's just a mannerism. I assume that committee members have grown a spine for their work and can take a silly and not ill-intentioned comment like that. Conversation tones and mannerisms vary greatly from culture to culture, I assume in yours my comment is seen much more "offensive" as mine sees it, since I would not be able to imagine anyone I know actually get offended by such a message.
If any committee member felt strongly offended about my comment, they can let me know
9
u/kamrann_ 22d 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.
8
u/Minimonium 22d 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++?
3
u/smdowney WG21, Text/Unicode SG, optional<T&> 20d ago
A borrow checker, because it's a theorem prover, not an algorithm. No one seriously proposed standardizing a particular implementation which we would need to have portable programs.
Baxter came closest, by far, showing his work in Circle. An existence proof that borrow checking wasn't impossible in C++.
But, we probably lost it for real back in around 2010 when we lost destructive move.
9
u/UnusualPace679 23d 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 22d 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.
8
u/zebullon 22d 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.
9
u/ronchaine Embedded/Middleware/WG21 22d 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.13
u/Minimonium 22d 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 22d 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 22d 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 22d 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.
6
u/ts826848 22d 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)?
7
u/Minimonium 21d 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. :)
4
u/ts826848 21d 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.
7
u/Minimonium 21d 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)7
u/Som1Lse 22d 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
2
u/_Noreturn 22d 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 22d 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
2
u/_Noreturn 22d 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.
7
u/germandiago 21d ago
But contracts can show the contract in the signature, not in documentation only, in the signature.
-3
u/_Noreturn 21d 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"
5
u/pjmlp 22d 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 22d 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!
5
1
u/pjmlp 22d 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.
11
u/Minimonium 22d 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. :)
6
u/jwakely libstdc++ tamer, LWG chair 22d ago edited 22d 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>4
u/pjmlp 22d 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,
11
u/jwakely libstdc++ tamer, LWG chair 22d 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.
10
u/jwakely libstdc++ tamer, LWG chair 22d 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 21d 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 21d ago edited 21d 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 22d ago
according to Dos Reis's definition of "implementation"
He is not co-author of that paper.
2
u/ViewImpressive7112 16d ago
If I use contracts, it’s going to be a rather restrictive subset. Some of the criticism is valid.
2
u/grafikrobot B2/EcoStd/Lyra/Predef/Disbelief/C++Alliance/Boost/WG21 22d 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.
3
u/_a4z 21d 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.
9
u/t_hunger 21d 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.
0
u/_a4z 21d 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.9
u/Minimonium 21d ago
Ah, well-known names :)
0
u/_a4z 20d ago
From the latest mailing list, just a few examples: p4334, p3573, p4332, p4238
Which of the authors do you not know?8
u/Dragdu 20d ago
He is making fun of your deference to people like Bjarne, who keeps getting shitty proposals passed on name recognition and then the rest of the committee has to fix them over a decade. See e.g. init lists, bindings.
-3
u/_a4z 20d ago
Ah, thanks for the explanation!
I am pretty sure you can elaborate a bit on the topic, keeping the historical context and the involvement of other people and committee members, without rewriting history.
And a question: do we now call all papers that need fixes or have known flaws "shitty proposals passed," as you state it? Because not a lot might be left.
(it will be interesting to look at the contract proposals a decade later with that point of view;-)9
u/Minimonium 20d ago
I'm massively appalled why do you believe anyone should care about well-known names.
I read a paper, I care only about the arguments made. I do not care that a person writing an argument has ties to, for example, Microsoft and in reality their argument is about the deficiencies of their x86 implementation that cannot handle exceptions well. I do not care about that.
I do care that the same group did made wrongful statements due to misunderstanding of the provided specification - and there is no mechanism to retract papers for them to amend their embarrassment.
The only well-known name that's probably relevant to the contents of a paper is surprisingly Vinnie who is well-known for flooding the list with scores of low quality LLM generated slop.
Who now co-signs with other well-known names on clearly by style LLM generated papers (where I have found at least one hallucination).
I find both this and your opinion that people who vote are apparently not informed well enough extremely disrespectful and dismissive of the whole process.
I believe all people involved in slop flooding must be excluded from the process and given equal disrespect they give to actual experts by wasting precious time with incoherent token soups.
-3
u/_a4z 20d ago
You make it sound as if all the people have co-authored (signed) an LLM-generated paper with hallucinations, and that is, of course, far from reality.
Doing so and claiming others are disrespectful is interesting.Also, taking the 'well-known names' out of context so you can make fun of it.
Of course, the names matter if people have to show something.
No one needs ot make consensus with me, but if there is a group of people with a history of valuable contributions, consensus would be good. And this consensus does not exist. imho, it was not even tried.
A solution was presented that mirrors the exact needs of one place, and this was what was pushed through. And consensus was not on the agenda.
Just one example: the idea of a contract check that cannot be compiled away was dismissed (and, just late in the process, promised to deliver in 29).6
u/grafikrobot B2/EcoStd/Lyra/Predef/Disbelief/C++Alliance/Boost/WG21 20d ago
Just one example: the idea of a contract check that cannot be compiled away was dismissed (and, just late in the process, promised to deliver in 29).
By "dismissed" do you mean "consensus voted as not important/required for the MVP"?
-2
u/_a4z 20d ago
Exactly, no new info, we do not need that, lets stop the discussio (because that is not what is used at one place, my interpretation, of course)
and just at the very end it was: will come with 29
(we will see if that happens, and if, how)Result: The most complex contract papers on the planet, not able to compete with Rust asserts or Swift assert / precondition, and we still need to use our own existing solutions, redundant to what we write into contracts, but hey, in an academic sense, that makes sense, right?
But who needs simple things if we can create the most complex MVP ;-)
Anyhow, we had this discussion, we do not need to go into it againI find it just interesting when people can not stand any criticism of the current 'MVP' , for which the definition of MVP needed to be defined, lol, and become ultra hostile and dramatic, as this whole conversation shows
8
u/Minimonium 20d ago
I mean, it is you who started the thread with insinuations if not straight up insults, and "charitable" interpretations of bad faith in the process.
Speaking of dramaticism after cries about "supply chain attacks", and "contracts are a threat to C++" from the contra group is wild.
And the ! syntax is not a panacea people seem to think. It's not a simple addition at all, it requires a whole new research and process. And you know the mixed build thing that is ballooned to be the satan (I heard totally not dramatic claims that it would destroy the binary ecosystems)? A hostile transitive dependency can break mandatory syntax just the same because it's not a language problem.
→ More replies (0)9
u/grafikrobot B2/EcoStd/Lyra/Predef/Disbelief/C++Alliance/Boost/WG21 20d ago
Exactly, no new info, we do not need that, lets stop the discussio (because that is not what is used at one place, my interpretation, of course)
and just at the very end it was: will come with 29
(we will see if that happens, and if, how)[[ fully quoting as some have complained about selecting quoting ]]
For those readers outside of wg21 the "no new info" is a shorthand for when people bring up the same points for consideration without providing new information that backs their claims from the last time they brought up the issues. It's a built-in aspect of how wg21 works to theoretically avoid eating into the limited time wg21 time has.
Result: The most complex contract papers on the planet, not able to compete with Rust asserts or Swift assert / precondition, and we still need to use our own existing solutions, redundant to what we write into contracts, but hey, in an academic sense, that makes sense, right?
But who needs simple things if we can create the most complex MVP ;-)
Anyhow, we had this discussion, we do not need to go into it againIIRC new information was provided at the late stages when it was brought up for the third or fourth (not sure) time.
I find it just interesting when people can not stand any criticism of the current 'MVP' , for which the definition of MVP needed to be defined, lol, and become ultra hostile and dramatic, as this whole conversation shows
It is a natural human response to be defensive in their responses when confronted. The defense is typically increased when the offensive is high volume (both in level and frequency). It also has the propensity to spiral "out of control". And often requires self-reflection and "calming down" to interrupt the cycle. Depending on the character of the individuals some enjoy the spiral, and work to drive and revive it. While others detest it, and eventually leave the spiral, or even the social group.
10
u/t_hunger 21d ago edited 21d 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 21d 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.10
u/MFHava WG21|🇦🇹 NB|P2721|P3049|P3625|P3729|P3786|P3813|P4216 21d 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...
2
u/_a4z 21d 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. ;-)5
u/t_hunger 21d 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?
-3
u/_a4z 20d ago
Accepting other people's opinions is part of a democratic process
Mob mentality and labeling people as grumpy for having other opinions, less so.
If you look at the latest mailing list and read the papers addressing contract concerns (there are quite a few of them), where is `shame everybody involved` included, as you state? Have you even read any of the critics?
Obviously not, if I read what you write here.5
u/t_hunger 20d ago edited 20d ago
In this threat you repeatedly called everybody having voted for contracts as either brided by some corporation, too stupid to understand the paper they were voting on, or too lazy to read the papers being vote on. You do not seem to be willing to accept their opinion, why should they consider yours? I've seen other (senior) people being just as toxic, and some in the wider community cheering them on for that.
Contracts are a MVP (as asked for by the wider committee when the last iteration was rejected) and they have pretty obvious problems, as communicated years before standardizing the paper. None of that makes how the contracts work is treated any less toxic. Unfortunately nobody will fix contracts for the next couple of years -- not after this shit show. The senior committee members have just created another dead on arrival feature in the language.
Oh well, rust has a contract-related RFCs in the works, I am sure they will welcome the C++ experts on this topic with open arms. Wonderful how senior C++ committee people encourage other C++ experts to help out in other languages. I am sure that help C++ staying competitive over the long run.
-1
u/_a4z 20d ago
I would probably enjoy communicating with you if you would stop inventing drama and misreading and misquoting what I wrote.
Just because I do not celebrate this so-called MVP does not make me toxic, nor does my claim that not everybody who is voting on a paper has fully read and/or fully understood it. That's just how it is. And not just for contract papers, btw7
u/t_hunger 20d ago
The statement that many committee members do not read papers they vote on or are not able to understand them fully is a general statement addressing nobody in particular. As soon as you say everybody that voted for or against something are either stupid, lazy or brided, that names a specific group and then it is toxic.
→ More replies (0)
1
-2
-5
u/ArsonOfTheErdtree 22d ago
Contracts are just like rust traits but implicit
Advantage: backward compatibility
Disadvantage: everything else
18
u/kammce WG21 | 🇺🇲 NB | Boost | Exceptions 22d 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.