3 ms·

I implemented Contracts in the C++ language in the early 90's as an extension. Nobody wanted it. https://www.digitalmars.com/ctg/contract.html https://www.dig

I implemented Contracts in the C++ language in the early 90's as an extension. Nobody wanted it. https://www.digitalmars.com/ctg/contract.html https://www.digitalmars.com/ctg/contract.html

ChrisGreenHeur 7mo ago
it could be possible that llms can mak great use of them
- sidkshatriya 7mo ago
  > it could be possible that llms can mak great use of them This is actually a good point. Yes, LLMs have saturated the conversation everywhere but contracts help clarify the pre-post conditions of methods well. I don't know how good the implementation in C++ will be but LLMs should be able to really exploit them well.
  - quuxplusone 7mo ago
    The problem with that is that C++26 Contracts are just glorified asserts. They trigger at runtime, not compile time. So if your LLM-generated code would have worked 99% of the time and then crashed in the field... well, now it will work 99% of the time and (if you're lucky) call the contract-violation handler in the field. Arguably that's better (more predictable misbehavior) than the status quo. But it's not remotely going to fix the problem with LLM-generated code, which is that you can't trust it to behave correctly in the corner cases. Contracts can't make the code magically behave better; all they can do is make it misbehave better.
    - celrod 7mo ago
      In my experience, llms don't reason well about expected states, contracts, invariants, etc. Partly because that don't have long term memory and are often forced to reason about code in isolation. Maybe this means all invariants should go into AGENTS.md/CLAUDE.md files, or into doc strings so a new human reader will quickly understand assumptions. Regardless, I think a habit of putting contracts to make pre- and post-conditions clear could help an AI reason about code. Maybe instead of suggesting a patch to cover up a symptom, an AI may reason that a post-condition somewhere was violated, and will dig towards the root cause. This applies just as well to asserts, too. Contracts/asserts actually need to be added to tell a reader something.
mort96 7mo ago
How do you know nobody wanted it?
- sidkshatriya 7mo ago
  > How do you know nobody wanted it? Some imperfect data points on how to judge if a language feature is wanted (or not): - Discussion on forums about how to use the feature - Programs in the wild using the feature - Bug reports showing people trying to use the feature and occasionally producing funny interactions with other parts of the language - People wanting to do more complex things on the initially built feature by filing features requests. (Showing that there is uptake on the feature and people want to do more fancy advanced things)
- WalterBright 7mo ago
  I listen to the users. There was never any mention of it.
locknitpicker 7mo ago
> Nobody wanted it. The fact that the C++ standard community has been working on Contracts for nearly a decade is something that by itself automatically refutes your claim. I understand you want to self-promote, but there is no need to do it at the expense of others. I mean, might it be that your implementation sucked?
- happyweasel 7mo ago
  In the early 1990s, C++ had not yet been standardized by ISO, so your argument doesn’t apply to that period.
- vintagedave 7mo ago
  Late nineties is approaching thirty decades ago; if the C++ committee has now been working on this for nearly a decade, that's fifteen to twenty years of them not working on it. It's quite plausible that contracts simply weren't valued at the time. Also, in my view the committee has been entertaining wider and wider language extensions. In 2016 there was a serious proposal for a graphics API based on (I think) Cairo. My own sense is that it's out of control and the language is just getting stuff added on because it can. Contracts are great as a concept, and it's hard to separate the wild expanse of C++ from the truly useful subset of features. There are several things proposed in the early days of C++ that arguably should be added.
  - retsibsi 7mo ago
    > Late nineties is approaching thirty decades ago Boy, this makes me feel old... oh wait :) (I agree with your point; early 90s vs. mid-10s are two very different worlds, in this context.)
    - vintagedave 7mo ago
      Wow. It’s such a funny typo I wouldn’t correct it now even if I was still able to edit. So what was it like back in the Egyptian age? :)
  - germandiago 7mo ago
Twey 7mo ago
I think it's also true that, regardless of the desirability of the feature at the time (which sibling comments discuss eloquently) people who've bought into a language are usually quite wary of also buying into extensions to that language. The very act of ratification by the committee gives this proposal a ‘feature’ that the DMC++ extension lacked in compatibility expectations over time and across implementations — it's not necessarily a comment on the technical quality or desirability of the work itself.
Defletter 7mo ago
But then why did you add your contract system to D? You implemented your contract system in the "early 90's", and D was released in 2001, so that's near a decade of "nobody wanted it". So then why add them as a core language feature of a new programming language if no one wanted it? Why is it still a core language feature? And why object to C++ finally adding contracts. I just don't get what you're even arguing here.
- WalterBright 7mo ago
  It's a great question! I simply had faith that it was a good idea. The reason I started D in the first place is the C++ community was uninterested in any of my ideas for improvement. Ironically, C++ would up adopting a lot of them one by one! Such as contracts! Contracts did find an enthusiastic constituency in the D community.
  - Defletter 7mo ago
    Contracts are a good idea, but I find the implementation of them to be clunky. I'd much rather contracts be part of the type system than as function signatures. Using the example in your earlier link, instead of defining day's 1..31 range within the Date-struct invariant, you'd instead declare a "day" type that's an int whose value cannot exceed 31 or be less than 1. This would be checked and enforced anytime a variable of the type is [re]assigned, set as a field, or passed-in as a parameter.

I implemented Contracts in the C++ language in the early 90's as an extension. Nobody wanted it. https://www.digitalmars.com/ctg/contract.html https://www.digitalmars.com/ctg/contract.html

ChrisGreenHeur 7mo ago

it could be possible that llms can mak great use of them

sidkshatriya 7mo ago
> it could be possible that llms can mak great use of them This is actually a good point. Yes, LLMs have saturated the conversation everywhere but contracts help clarify the pre-post conditions of methods well. I don't know how good the implementation in C++ will be but LLMs should be able to really exploit them well.
- quuxplusone 7mo ago
  The problem with that is that C++26 Contracts are just glorified asserts. They trigger at runtime, not compile time. So if your LLM-generated code would have worked 99% of the time and then crashed in the field... well, now it will work 99% of the time and (if you're lucky) call the contract-violation handler in the field. Arguably that's better (more predictable misbehavior) than the status quo. But it's not remotely going to fix the problem with LLM-generated code, which is that you can't trust it to behave correctly in the corner cases. Contracts can't make the code magically behave better; all they can do is make it misbehave better.
  - celrod 7mo ago
    In my experience, llms don't reason well about expected states, contracts, invariants, etc. Partly because that don't have long term memory and are often forced to reason about code in isolation. Maybe this means all invariants should go into AGENTS.md/CLAUDE.md files, or into doc strings so a new human reader will quickly understand assumptions. Regardless, I think a habit of putting contracts to make pre- and post-conditions clear could help an AI reason about code. Maybe instead of suggesting a patch to cover up a symptom, an AI may reason that a post-condition somewhere was violated, and will dig towards the root cause. This applies just as well to asserts, too. Contracts/asserts actually need to be added to tell a reader something.

mort96 7mo ago

How do you know nobody wanted it?

sidkshatriya 7mo ago
> How do you know nobody wanted it? Some imperfect data points on how to judge if a language feature is wanted (or not): - Discussion on forums about how to use the feature - Programs in the wild using the feature - Bug reports showing people trying to use the feature and occasionally producing funny interactions with other parts of the language - People wanting to do more complex things on the initially built feature by filing features requests. (Showing that there is uptake on the feature and people want to do more fancy advanced things)
WalterBright 7mo ago
I listen to the users. There was never any mention of it.

locknitpicker 7mo ago

> Nobody wanted it. The fact that the C++ standard community has been working on Contracts for nearly a decade is something that by itself automatically refutes your claim. I understand you want to self-promote, but there is no need to do it at the expense of others. I mean, might it be that your implementation sucked?

happyweasel 7mo ago
In the early 1990s, C++ had not yet been standardized by ISO, so your argument doesn’t apply to that period.
vintagedave 7mo ago
Late nineties is approaching thirty decades ago; if the C++ committee has now been working on this for nearly a decade, that's fifteen to twenty years of them not working on it. It's quite plausible that contracts simply weren't valued at the time. Also, in my view the committee has been entertaining wider and wider language extensions. In 2016 there was a serious proposal for a graphics API based on (I think) Cairo. My own sense is that it's out of control and the language is just getting stuff added on because it can. Contracts are great as a concept, and it's hard to separate the wild expanse of C++ from the truly useful subset of features. There are several things proposed in the early days of C++ that arguably should be added.
- retsibsi 7mo ago
  > Late nineties is approaching thirty decades ago Boy, this makes me feel old... oh wait :) (I agree with your point; early 90s vs. mid-10s are two very different worlds, in this context.)
  - vintagedave 7mo ago
    Wow. It’s such a funny typo I wouldn’t correct it now even if I was still able to edit. So what was it like back in the Egyptian age? :)
- germandiago 7mo ago

Twey 7mo ago

I think it's also true that, regardless of the desirability of the feature at the time (which sibling comments discuss eloquently) people who've bought into a language are usually quite wary of also buying into extensions to that language. The very act of ratification by the committee gives this proposal a ‘feature’ that the DMC++ extension lacked in compatibility expectations over time and across implementations — it's not necessarily a comment on the technical quality or desirability of the work itself.

Defletter 7mo ago

But then why did you add your contract system to D? You implemented your contract system in the "early 90's", and D was released in 2001, so that's near a decade of "nobody wanted it". So then why add them as a core language feature of a new programming language if no one wanted it? Why is it still a core language feature? And why object to C++ finally adding contracts. I just don't get what you're even arguing here.

WalterBright 7mo ago
It's a great question! I simply had faith that it was a good idea. The reason I started D in the first place is the C++ community was uninterested in any of my ideas for improvement. Ironically, C++ would up adopting a lot of them one by one! Such as contracts! Contracts did find an enthusiastic constituency in the D community.
- Defletter 7mo ago
  Contracts are a good idea, but I find the implementation of them to be clunky. I'd much rather contracts be part of the type system than as function signatures. Using the example in your earlier link, instead of defining day's 1..31 range within the Date-struct invariant, you'd instead declare a "day" type that's an int whose value cannot exceed 31 or be less than 1. This would be checked and enforced anytime a variable of the type is [re]assigned, set as a field, or passed-in as a parameter.