4 ms·

Contracts for C++ (DbC) [pdf]

53 points by xo5vik 2y ago

pbrowne011 2y ago
More recent revision: https://isocpp.org/files/papers/P2900R10.pdf https://isocpp.org/files/papers/P2900R10.pdf. It seems like they've added a few things since this draft. It's somewhat funny to hear "minimum viable product" in the context of a language standard/specification. I'd never thought of adding a feature to a language in that way before. The idea of design by contract (DbC) in C++ appears to have been around for a while too. The authors link to a "forthcoming companion paper" (currently a 404 error), but you can find proposals from as early as 2004 with the idea: https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1613.pdf https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n16... (and potentially earlier, I just haven't seen one yet)
- WalterBright 2y ago
  You have now :-)
- pjmlp 2y ago
  Languages are software products as well. Many features in Java, C#, C++ have evolved as MVP across several language revisions before. Lambdas, type inference, modules, unsafe code, constexpr,...
- gpderetta 2y ago
  This is the MVP, as the subset of the all the various contract proposals that stands a chance to pass approval, as the feature has been extremely contentious with irreconcilable positions on some details.
arunc 2y ago
Are there HTML version of these docs? Would make it easier to read without having to download a PDF.
- WalterBright 2y ago
  The pdf rendered nicely for me.
discardable_dan 2y ago
I did my dissertation work on software contracts. They are generally useless: programmers won't write them, or will write them incorrectly. Moreover, the runtime enforcement dominates all but the most-expensive functions, and contracts become an antipattern for helper functions due to their enforcement cost. Without intense compiler support and contract erasure such as David Van Horne's work, this is a dead idea that needs to stay that way.
- fermigier 2y ago
  A reference for your dissertation? The usefulness (or lack thereof) of contracts was famously discussed in 1997 in this paper: https://www.irisa.fr/pampa/EPEE/Ariane5.html https://www.irisa.fr/pampa/EPEE/Ariane5.html (with additional comments here: https://www.irisa.fr/pampa/EPEE/Ariane5-comments.html https://www.irisa.fr/pampa/EPEE/Ariane5-comments.html ). I have tried several times (a couple of decades ago) to introduce DBC in Python, using one of the many available libraries (for an overview: see https://lab.abilian.com/Tech/Python/DbC%20in%20Python/ https://lab.abilian.com/Tech/Python/DbC%20in%20Python/ ) but, like you, wasn't convinced. I believe your argument on the performance penalty is right, and as a corollary, this implies that contracts are mostly useful if associated with a formal proof system. Contracts in production are probably a bad idea, in most cases.
  - pschanely 2y ago
    > I believe your argument on the performance penalty is right, and as a corollary, this implies that contracts are mostly useful if associated with a formal proof system. Contracts in production are probably a bad idea, in most cases. Agree! There is a sliding scale between testing contracts and proving them too. My labor of love for the past several years has been a tool for checking Python contracts using an SMT solver (using symbolic inputs over concrete paths): https://github.com/pschanely/CrossHair https://github.com/pschanely/CrossHair That said, these days I think property-based testing gets you the ~same benefits as contracts, and is easier for most people to apply.
  - mempko 2y ago
    Wow, people miss the point of contracts. You never want to turn them off in production, because that's where all the weird shit happens that you never thought of. Contracts catch bugs in those times. Maybe people find them useless precisely because they turn them off.
WalterBright 2y ago
Contract programming for C++ was implemented back in the 90's. https://www.digitalmars.com/ctg/contract.html https://www.digitalmars.com/ctg/contract.html It also appears in the D programming language: https://dlang.org/spec/contracts.html https://dlang.org/spec/contracts.html
- kazinator 2y ago
  The programming world has massive anterograde amnesia.
- fermigier 2y ago
  "Contract programming for C++ was implemented back in the 90's." -> Did the proposal authors contact you or refer to your work (or any other previous work)? It not, that would be a shame. "It also appears in the D programming language" -> Do people use it?
  - WalterBright 2y ago
    > Did the proposal authors contact you No > or refer to your work (or any other previous work)? No I presume they simply didn't know about it. I emailed the authors. > Do people use it? Yes
    - zerr 2y ago
      > Yes The tiny subset of D userbase, which is tiny in its own.
    - AlotOfReading 2y ago
      I'd assume the authors were aware of it, given that the original set of proposals from 2004-2006 directly compares facilities in D and Eiffel. Plus, you know, andrei. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1962.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n19...
      - WalterBright 2y ago
tialaramex 2y ago
Assuming that this or something substantially identical does land for C++ 26 I think we should start betting on when SG23 (the committee's Study Group for "Safety and Security") is replaced by some hypothetical SG24 "Safety and Security No But Really". We already know that because C++ Undefined Behaviour can cause what are called "Time Travel" defects and this paper doesn't do anything to prevent it, adding contracts in C++ can make your software less safe and induce more surprise behaviour. We also already know that C++ programmers tend to write erroneous UB tests when trying to grapple with edge cases that might induce Undefined Behaviour, setting off the very calamity they fear. So this new feature, rather than being (as its proponents claim) a way to improve the safety of C++ software, or neutrally becoming a dead letter as the UB "passes" contracts that in fact are not met, might instead become another footgun for the language. A functioning SG23 should have caused this proposal to stall out until it can explain how it will prevent this problem, rather than merely re-stating the problem (in 3.6.4) and saying well that's unfortunate but maybe somebody else will fix it. That stance might be extremely unpopular with some C++ programmers, who believe they don't make mistakes, but as it stands this work will instead cause all the people who do make mistakes (which is in practice everybody) to regret using contracts. If SG23 isn't interested in preventing C++ from becoming even more unsafe, what's the point in the group existing?
- tialaramex 2y ago
  Aha, this for some reason links an ancient version of the proposal and current versions do forbid time travel across the contract, so, the result is not strictly worse which is an important improvement, no sure whether SG23 was involved in that outcome but it's a good idea either way.
- gpderetta 2y ago
  Prohibiting time traveling UB in all cases is proposed by P3352 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3352r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p33...).
- bluGill 2y ago
  SG23 has done a lot in C++26 around this.
justneedaname 2y ago
Anyone interested in other languages that implement this should take a look at the SPARK subset of Ada. Pre and postconditions work in the same way and enforce the same behaviour described here (or at least that's what I understand it to do from a quick skim through)
- bluGill 2y ago
  The authors are aware of SPARK and are trying to bring that to C++.
- rwmj 2y ago
  Wasn't Eiffel the first "design by contract" language? https://en.wikipedia.org/wiki/Eiffel_(programming_language) https://en.wikipedia.org/wiki/Eiffel_(programming_language)
  - pjmlp 2y ago
    Yes, with key books based on it.
smallstepforman 2y ago
For decades we have been using assert(input) and assert(output), so it's not exactly new. Forcing sanitary checks by the language runtime is an option, hence requiring contracts to spell out the range of valid input/output which is checked in debug mode. Otherwise, if it's optional, it will only be used by a subset of engineers. If its mandatory, it can cripple performance (unless we have unsafe scopes). Opt-out is always better than opt-in.
ysguemency2003 2y ago
[dead]

53 points by xo5vik 2y ago

More recent revision: https://isocpp.org/files/papers/P2900R10.pdf https://isocpp.org/files/papers/P2900R10.pdf. It seems like they've added a few things since this draft. It's somewhat funny to hear "minimum viable product" in the context of a language standard/specification. I'd never thought of adding a feature to a language in that way before. The idea of design by contract (DbC) in C++ appears to have been around for a while too. The authors link to a "forthcoming companion paper" (currently a 404 error), but you can find proposals from as early as 2004 with the idea: https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1613.pdf https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n16... (and potentially earlier, I just haven't seen one yet)

WalterBright 2y ago
You have now :-)
pjmlp 2y ago
Languages are software products as well. Many features in Java, C#, C++ have evolved as MVP across several language revisions before. Lambdas, type inference, modules, unsafe code, constexpr,...
gpderetta 2y ago
This is the MVP, as the subset of the all the various contract proposals that stands a chance to pass approval, as the feature has been extremely contentious with irreconcilable positions on some details.

arunc 2y ago

Are there HTML version of these docs? Would make it easier to read without having to download a PDF.

WalterBright 2y ago
The pdf rendered nicely for me.

discardable_dan 2y ago

I did my dissertation work on software contracts. They are generally useless: programmers won't write them, or will write them incorrectly. Moreover, the runtime enforcement dominates all but the most-expensive functions, and contracts become an antipattern for helper functions due to their enforcement cost. Without intense compiler support and contract erasure such as David Van Horne's work, this is a dead idea that needs to stay that way.

fermigier 2y ago
A reference for your dissertation? The usefulness (or lack thereof) of contracts was famously discussed in 1997 in this paper: https://www.irisa.fr/pampa/EPEE/Ariane5.html https://www.irisa.fr/pampa/EPEE/Ariane5.html (with additional comments here: https://www.irisa.fr/pampa/EPEE/Ariane5-comments.html https://www.irisa.fr/pampa/EPEE/Ariane5-comments.html ). I have tried several times (a couple of decades ago) to introduce DBC in Python, using one of the many available libraries (for an overview: see https://lab.abilian.com/Tech/Python/DbC%20in%20Python/ https://lab.abilian.com/Tech/Python/DbC%20in%20Python/ ) but, like you, wasn't convinced. I believe your argument on the performance penalty is right, and as a corollary, this implies that contracts are mostly useful if associated with a formal proof system. Contracts in production are probably a bad idea, in most cases.
- pschanely 2y ago
  > I believe your argument on the performance penalty is right, and as a corollary, this implies that contracts are mostly useful if associated with a formal proof system. Contracts in production are probably a bad idea, in most cases. Agree! There is a sliding scale between testing contracts and proving them too. My labor of love for the past several years has been a tool for checking Python contracts using an SMT solver (using symbolic inputs over concrete paths): https://github.com/pschanely/CrossHair https://github.com/pschanely/CrossHair That said, these days I think property-based testing gets you the ~same benefits as contracts, and is easier for most people to apply.
- mempko 2y ago
  Wow, people miss the point of contracts. You never want to turn them off in production, because that's where all the weird shit happens that you never thought of. Contracts catch bugs in those times. Maybe people find them useless precisely because they turn them off.

WalterBright 2y ago

Contract programming for C++ was implemented back in the 90's. https://www.digitalmars.com/ctg/contract.html https://www.digitalmars.com/ctg/contract.html It also appears in the D programming language: https://dlang.org/spec/contracts.html https://dlang.org/spec/contracts.html

kazinator 2y ago
The programming world has massive anterograde amnesia.
fermigier 2y ago
"Contract programming for C++ was implemented back in the 90's." -> Did the proposal authors contact you or refer to your work (or any other previous work)? It not, that would be a shame. "It also appears in the D programming language" -> Do people use it?
- WalterBright 2y ago
  > Did the proposal authors contact you No > or refer to your work (or any other previous work)? No I presume they simply didn't know about it. I emailed the authors. > Do people use it? Yes
  - zerr 2y ago
    > Yes The tiny subset of D userbase, which is tiny in its own.
  - AlotOfReading 2y ago
    I'd assume the authors were aware of it, given that the original set of proposals from 2004-2006 directly compares facilities in D and Eiffel. Plus, you know, andrei. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1962.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n19...
    - WalterBright 2y ago

tialaramex 2y ago

Assuming that this or something substantially identical does land for C++ 26 I think we should start betting on when SG23 (the committee's Study Group for "Safety and Security") is replaced by some hypothetical SG24 "Safety and Security No But Really". We already know that because C++ Undefined Behaviour can cause what are called "Time Travel" defects and this paper doesn't do anything to prevent it, adding contracts in C++ can make your software less safe and induce more surprise behaviour. We also already know that C++ programmers tend to write erroneous UB tests when trying to grapple with edge cases that might induce Undefined Behaviour, setting off the very calamity they fear. So this new feature, rather than being (as its proponents claim) a way to improve the safety of C++ software, or neutrally becoming a dead letter as the UB "passes" contracts that in fact are not met, might instead become another footgun for the language. A functioning SG23 should have caused this proposal to stall out until it can explain how it will prevent this problem, rather than merely re-stating the problem (in 3.6.4) and saying well that's unfortunate but maybe somebody else will fix it. That stance might be extremely unpopular with some C++ programmers, who believe they don't make mistakes, but as it stands this work will instead cause all the people who do make mistakes (which is in practice everybody) to regret using contracts. If SG23 isn't interested in preventing C++ from becoming even more unsafe, what's the point in the group existing?

tialaramex 2y ago
Aha, this for some reason links an ancient version of the proposal and current versions do forbid time travel across the contract, so, the result is not strictly worse which is an important improvement, no sure whether SG23 was involved in that outcome but it's a good idea either way.
gpderetta 2y ago
Prohibiting time traveling UB in all cases is proposed by P3352 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3352r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p33...).
bluGill 2y ago
SG23 has done a lot in C++26 around this.

justneedaname 2y ago

Anyone interested in other languages that implement this should take a look at the SPARK subset of Ada. Pre and postconditions work in the same way and enforce the same behaviour described here (or at least that's what I understand it to do from a quick skim through)

bluGill 2y ago
The authors are aware of SPARK and are trying to bring that to C++.
rwmj 2y ago
Wasn't Eiffel the first "design by contract" language? https://en.wikipedia.org/wiki/Eiffel_(programming_language) https://en.wikipedia.org/wiki/Eiffel_(programming_language)
- pjmlp 2y ago
  Yes, with key books based on it.

smallstepforman 2y ago

For decades we have been using assert(input) and assert(output), so it's not exactly new. Forcing sanitary checks by the language runtime is an option, hence requiring contracts to spell out the range of valid input/output which is checked in debug mode. Otherwise, if it's optional, it will only be used by a subset of engineers. If its mandatory, it can cripple performance (unless we have unsafe scopes). Opt-out is always better than opt-in.

ysguemency2003 2y ago

[dead]