Hacker News Reader

Comment by WalterBright | Hacker News Reader

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

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.

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.

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.

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.

How do you know nobody wanted it?

> 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)

I listen to the users. There was never any mention of it.

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

> 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.

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.

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.

> 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?

In the early 1990s, C++ had not yet been standardized by ISO, so your argument doesn’t apply to that period.

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.

> 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.)

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? :)

I am not sure what the "truly useful features are" if you take into account that C++ goes from games to servers to embedded, audio, heterogeneous programming, some GUI frameworks, real-time systems (hard real-time) and some more.

I would say some of the features that are truly useful in some niches are les s imoortant in others and viceversa.

> I understand you want to self-promote

Not a very fair assumption. However, even if your not so friendly point was even true, I'd like people who have invented popular languages to "self-promote" more (here dlang). It is great to get comments on HN from people who have actually achieved something nice !

35 years is a lot longer than a decade. C++ should have copied the '= void;' syntax, too!

It should copy Zig's '= undefined;' instead of D's '= void;' The latter is very confusing: why have a keyword that means nothing, but also anything? This is a pretty common flaw within D, see also: static.

Nobody in D was confused by `= void;`. People understood it immediately.

> why have a keyword that means nothing, but also anything?

googling void: "A void is a space containing nothing, a feeling of utter emptiness, or a legal nullity, representing a state of absolute vacancy or lack."

Sounds perfect!

"People" doesn't include me then. I had no idea that D had this feature for quite some time, despite using it fairly often in Zig, because when considering what the equivalent would be to search for, my brain somehow didn't make the leap to the keyword that represents literally nothing. Or as your Google search result says, "representing a state of absolute vacancy or lack." A less inappropriate use of "= void;" would be to zero-out something. I honestly find D's continual misuse of keywords like this to be really off putting and a contributing factor as to why I've stopped using it.

Reply on news.ycombinator.com