Narrow Contracts and `noexcept` are Inherently Incompatible in C++
summary
Argues that the Lakos Rule forbids adding `noexcept` to any function with a narrow contract because `noexcept` changes program behavior and the type-system view of a function, causing accidental termination, breaking negative tests and handlers that need to throw, and violating Liskov-style backward compatibility. Shows concrete examples (checked-vector vs checked-vector-with-`noexcept`, handler strategies: observe/enforce/trap), proves `noexcept` is only justified for move ops or as a non-queryable attribute like throws-nothing, and recommends keeping `noexcept` out of narrow-contract library specs.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 3:27Leos rule on noexcept and contracts
- 14:44Function contracts and preconditions
- 27:31Design by contract vs LSP
- 41:32LSP in practice and compatibility
- 57:46Why noexcept and contracts clash
- 1:03:00Handlers in safety systems
- 1:12:55When noexcept helps
- 1:20:46Conclusion and Q&A invitation
related talks
01h 28mEmbracing the **noexcept** Operator and Specifier *Safely*
58mAvoid Misuse of Contracts!
01h 17mFunction Contracts in Practice using C++
01h 22mContracts, Safety and Correctness in C++
01h 03m“What Could Possibly Go Wrong?: A Tale of Expectations and Exceptions”
44mError handling in C++: as easy as "use exceptions"?
01h 30mContracts, Safety, and the Art of Cat Herding
06mConstraints not Satisfied