UB cannot be prevented in this case:

Not all pre-conditions can be either easily specified or easily proven by the compiler.

Not following implicit pre-conditions may lead to UB.

The UB may already have been compiled into a third-party dynamic or static library.

Even informing the compiler at the call site about why the UB never happens, would not work for implicit pre-conditions and separately compiled UB. 

-----Ursprüngliche Nachricht-----
Von: Peter Bindels via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Mi 19.08.2026 15:31
Betreff: Re: [std-proposals] P4334R0 C++ Contracts
An: std-proposals@lists.isocpp.org;
CC: Peter Bindels <dascandy@gmail.com>;

 

On Wed, Aug 19, 2026 at 3:26 PM Rainer Deyke via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

On 8/19/26 05:37, Ville Voutilainen via Std-Proposals wrote:
> On Wed, 19 Aug 2026 at 05:54, Sebastian Wittmeier via Std-Proposals
> <std-proposals@lists.isocpp.org> wrote:
>>
>> If P2900 is staying, can you define (= propose) a 5th mode that acts like compile_assert and also hope that the implementations give better error messages and locations than an undefined violation handler?
>
> I don't know about others, but yes, yes I can: https://godbolt.org/z/xPz8hjcYY

I don't see the precondition violation.  `use_definitely_unsound` is a
perfectly fine function for getting a -1 so long as its implicit
precondition of not passing in a vector of exactly 5 elements is met.
Nothing in the program violates this implicit precondition.

Implicit preconditions still exist, right?  There is no way to encode
every precondition into something the compiler understands.

 

If a branch exists with definite UB but it's never called is the program still ill-formed? For my own software I want that to be yes, but for C++ in general I think so far we have no, and changing such a thing will be a breaking change for many.

-- 
 Std-Proposals mailing list
 Std-Proposals@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals