Date: Tue, 3 Mar 2026 10:49:37 +0000
Hi Alejandro
On 19/02/2026 15:43, Alejandro Colomar via Std-Proposals wrote:
> Hi Jan,
>
> On 2026-02-19T16:36:24+0100, Jan Schultke wrote:
>> On Thu, 19 Feb 2026 at 16:27, Alejandro Colomar <
>> une+cxx_std-proposals_at_[hidden]> wrote:
>>
>>> Hi Jan,
>>>
>>> On 2026-02-19T16:03:26+0100, Jan Schultke via Std-Proposals wrote:
>>>> What OP proposes could also be done separately from static analysis as a
>>>> compiler flag that requires the compiler to prove all contracts hold.
>>> This
>>>> essentially turns contract_assert into OP's compile_assert when the
>>>> semantic is ignore. In any case, I think contracts are the right way to
>>>> express conditions that should hold.
>>>
>>> I think contracts would have been less necessary with this feature.
>>> And in C, we certainly don't want contracts, while this API would be
>>> very nice.
>>>
>>
>> Well, there are some WG14 papers dealing with contracts. Never say never,
>> right?
>
> I'm aware of them. And I hate them; it's horrible.
>
>> Also, I don't think that having this feature would have made contracts less
>> necessary. None of the current contract evaluation semantics do what OP is
>> asking for. However, it would be possible to add a fifth "proof" contract
>> evaluation semantic, one step up from ignore. That makes it seem to me like
>> what OP proposes provides additional motivation for contracts in their
>> current state, since our C++26 design could be extended to provide
>> everything OP is asking for.
>>
>>
>>> You can implement "contracts" by wrapping functions in macros, and using
>>> this API to enforce conditions.
>>>
>>
>> Contracts can do a lot more. Notably, they let you specify function
>> contracts on declarations, not just in the body.
>
> That's essentially the same as:
>
> int foo(int x);
>
> #define foo(x) \
> ({ \
> compiler_assert(...); // contract \
> foo(x); \
> })
>
> Instead of writing a macro, you write a contract. I prefer the simpler
> code in a macro.
That's a good point, programmers can do things different ways.
I made a test file that shows use of compiler_assert() to enforce contracts at compile time (pre, post, contract_assert):
https://github.com/jonnygrant/compile_assert/blob/main/testsuite/main28_a.cpp
ie it pushes responsibility for the caller using class Number to only pass valid percentage double numbers within range 0..1
Only useful for things that can be reasoned at compile time. Of course the calling code can also validate the result after class Number is >0.0
Regards, Jonathan
On 19/02/2026 15:43, Alejandro Colomar via Std-Proposals wrote:
> Hi Jan,
>
> On 2026-02-19T16:36:24+0100, Jan Schultke wrote:
>> On Thu, 19 Feb 2026 at 16:27, Alejandro Colomar <
>> une+cxx_std-proposals_at_[hidden]> wrote:
>>
>>> Hi Jan,
>>>
>>> On 2026-02-19T16:03:26+0100, Jan Schultke via Std-Proposals wrote:
>>>> What OP proposes could also be done separately from static analysis as a
>>>> compiler flag that requires the compiler to prove all contracts hold.
>>> This
>>>> essentially turns contract_assert into OP's compile_assert when the
>>>> semantic is ignore. In any case, I think contracts are the right way to
>>>> express conditions that should hold.
>>>
>>> I think contracts would have been less necessary with this feature.
>>> And in C, we certainly don't want contracts, while this API would be
>>> very nice.
>>>
>>
>> Well, there are some WG14 papers dealing with contracts. Never say never,
>> right?
>
> I'm aware of them. And I hate them; it's horrible.
>
>> Also, I don't think that having this feature would have made contracts less
>> necessary. None of the current contract evaluation semantics do what OP is
>> asking for. However, it would be possible to add a fifth "proof" contract
>> evaluation semantic, one step up from ignore. That makes it seem to me like
>> what OP proposes provides additional motivation for contracts in their
>> current state, since our C++26 design could be extended to provide
>> everything OP is asking for.
>>
>>
>>> You can implement "contracts" by wrapping functions in macros, and using
>>> this API to enforce conditions.
>>>
>>
>> Contracts can do a lot more. Notably, they let you specify function
>> contracts on declarations, not just in the body.
>
> That's essentially the same as:
>
> int foo(int x);
>
> #define foo(x) \
> ({ \
> compiler_assert(...); // contract \
> foo(x); \
> })
>
> Instead of writing a macro, you write a contract. I prefer the simpler
> code in a macro.
That's a good point, programmers can do things different ways.
I made a test file that shows use of compiler_assert() to enforce contracts at compile time (pre, post, contract_assert):
https://github.com/jonnygrant/compile_assert/blob/main/testsuite/main28_a.cpp
ie it pushes responsibility for the caller using class Number to only pass valid percentage double numbers within range 0..1
Only useful for things that can be reasoned at compile time. Of course the calling code can also validate the result after class Number is >0.0
Regards, Jonathan
Received on 2026-03-03 10:49:41
