--- title: C++ Contracts - A Meaningfully Viable Product Part 2 description: A deep-dive conference talk (part 2) on C++ Contracts as proposed for C++26 via P2900. Covers syntactic restrictions including why contracts cannot be placed... canonical: https://daily.dev/posts/c-contracts---a-meaningfully-viable-product-part-2-jotsdk3eq twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: C++ Contracts - A Meaningfully Viable Product Part 2 | daily.dev og:description: A deep-dive conference talk (part 2) on C++ Contracts as proposed for C++26 via P2900. Covers syntactic restrictions including why contracts cannot be placed... og:url: https://daily.dev/posts/c-contracts---a-meaningfully-viable-product-part-2-jotsdk3eq og:image: https://api.daily.dev/og/posts/jotsDk3EQ.png og:image:alt: C++ Contracts - A Meaningfully Viable Product Part 2 og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # C++ Contracts - A Meaningfully Viable Product Part 2 **[C\+\+Online](https://daily.dev/sources/cpponline)** · 61 min read · 4 upvotes · 0 comments ## Summary A deep-dive conference talk (part 2) on C++ Contracts as proposed for C++26 via P2900. Covers syntactic restrictions including why contracts cannot be placed on defaulted functions or function pointers (ABI and type-system issues), preconditions in constructors and postconditions in destructors requiring explicit 'this', register-passing edge cases with mutable members in postconditions, lambda capture restrictions to preserve zero-overhead semantics, virtual function contract inheritance (deferred to C++29), compile-time contract evaluation semantics, coroutine-specific pitfalls with pre/postconditions, and the controversy around undefined behavior inside contract assertions including the rejected 'conveyor functions' proposal. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Will C++26 allow preconditions and postconditions on virtual functions? No, contracts on virtual functions are ill-formed in C++26. An earlier proposal distinguishing caller-side ('indirect') and callee-side ('implementation') contract evaluation had gained consensus but later lost it because the committee could not agree on what the default behavior should be when neither keyword was specified, so the feature was deferred to a future standard. _Anyone planning virtual function contract usage should track this C++26 restriction before it ships._ ### Can I put a precondition or postcondition on a function pointer in C++26? No, C++26 makes it ill-formed to apply pre- or post-conditions directly to a pointer-to-function variable, though a function itself can still have contracts checked when called through a pointer to it. The restriction exists because storing contract info in the pointer's type causes ABI and template instantiation problems, while storing it at runtime violates the zero-overhead principle, and no consensus solution was found in time. _Developers designing function-pointer-heavy APIs should watch this contracts limitation before adopting C++26._ ### Are postconditions safe to use with coroutines in C++26? Postconditions are supported in C++26 coroutines but are risky: since C++20, any const-by-value parameter to a coroutine is moved into the coroutine frame, so a postcondition capturing the initial parameter's address or value before the move can end up dangling. Preconditions and contract_assert remain safe since they only inspect the initial call parameters or non-address state. _Teams adopting coroutine contracts in C++26 should keep an eye on this gotcha before it bites production code._ ## Similar posts on daily.dev - [Contracts are in C\+\+26 despite disquiet over their value](https://daily.dev/posts/contracts-are-in-c-26-despite-disquiet-over-their-value-kccnzifgd) · DEVCLASS · 21 upvotes · 0 comments - [C\+\+26: Reflection, Memory Safety, Contracts, and a New Async Model](https://daily.dev/posts/c-26-reflection-memory-safety-contracts-and-a-new-async-model-qkor2ctht) · InfoQ · 18 upvotes · 2 comments - [CppCon 2026: Towards a complete contract-assertion fa...](https://daily.dev/posts/cppcon-2026-towards-a-complete-contract-assertion-fa--bcy9cniv5) · C\+\+ · 0 upvotes · 0 comments --- Tags: [#c++](https://daily.dev/tags/c++) [View this post on daily.dev](https://daily.dev/posts/c-contracts---a-meaningfully-viable-product-part-2-jotsdk3eq) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"C++ Contracts - A Meaningfully Viable Product Part 2","url":"https://daily.dev/posts/c-contracts---a-meaningfully-viable-product-part-2-jotsdk3eq","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/c-contracts---a-meaningfully-viable-product-part-2-jotsdk3eq"},"datePublished":"2026-07-13T16:03:50.194Z","dateModified":"2026-09-13T19:51:51.379Z","description":"A deep-dive conference talk (part 2) on C++ Contracts as proposed for C++26 via P2900. Covers syntactic restrictions including why contracts cannot be placed...","image":"https://i.ytimg.com/vi/1VUqOx6PCMU/sddefault.jpg","thumbnailUrl":"https://i.ytimg.com/vi/1VUqOx6PCMU/sddefault.jpg","isAccessibleForFree":true,"articleSection":"C++Online","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"C++Online","logo":"https://media.daily.dev/image/upload/s--8WzMvjLJ--/f_auto,q_auto/v1783236334/logos/cpponline","url":"https://daily.dev/sources/cpponline"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/c-contracts---a-meaningfully-viable-product-part-2-jotsdk3eq","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"c++","timeRequired":"PT61M","video":{"@type":"VideoObject","name":"C++ Contracts - A Meaningfully Viable Product Part 2","description":"A deep-dive conference talk (part 2) on C++ Contracts as proposed for C++26 via P2900. Covers syntactic restrictions including why contracts cannot be placed...","thumbnailUrl":"https://i.ytimg.com/vi/1VUqOx6PCMU/sddefault.jpg","uploadDate":"2026-07-13T16:03:50.194Z","duration":"PT61M","url":"https://api.daily.dev/r/jotsDk3EQ","embedUrl":"https://www.youtube.com/embed/1VUqOx6PCMU"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"C++Online","item":"https://daily.dev/sources/cpponline"},{"@type":"ListItem","position":3,"name":"C++ Contracts - A Meaningfully Viable Product Part 2"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/c-contracts---a-meaningfully-viable-product-part-2-jotsdk3eq#faq","mainEntity":[{"@type":"Question","name":"Will C++26 allow preconditions and postconditions on virtual functions?","acceptedAnswer":{"@type":"Answer","text":"No, contracts on virtual functions are ill-formed in C++26. An earlier proposal distinguishing caller-side ('indirect') and callee-side ('implementation') contract evaluation had gained consensus but later lost it because the committee could not agree on what the default behavior should be when neither keyword was specified, so the feature was deferred to a future standard. Anyone planning virtual function contract usage should track this C++26 restriction before it ships."}},{"@type":"Question","name":"Can I put a precondition or postcondition on a function pointer in C++26?","acceptedAnswer":{"@type":"Answer","text":"No, C++26 makes it ill-formed to apply pre- or post-conditions directly to a pointer-to-function variable, though a function itself can still have contracts checked when called through a pointer to it. The restriction exists because storing contract info in the pointer's type causes ABI and template instantiation problems, while storing it at runtime violates the zero-overhead principle, and no consensus solution was found in time. Developers designing function-pointer-heavy APIs should watch this contracts limitation before adopting C++26."}},{"@type":"Question","name":"Are postconditions safe to use with coroutines in C++26?","acceptedAnswer":{"@type":"Answer","text":"Postconditions are supported in C++26 coroutines but are risky: since C++20, any const-by-value parameter to a coroutine is moved into the coroutine frame, so a postcondition capturing the initial parameter's address or value before the move can end up dangling. Preconditions and contract_assert remain safe since they only inspect the initial call parameters or non-address state. Teams adopting coroutine contracts in C++26 should keep an eye on this gotcha before it bites production code."}}]} ```