Date: Sat, 14 Mar 2026 10:58:30 +0100
> On 11. Mar 2026, at 04:04, Jonathan Grant via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Hello Simon
>
> Many thanks for reviewing P4021.
>
>> On 07/03/2026 06:24, Simon Schröder via Std-Proposals wrote:
>>
>>
>>>> On Mar 5, 2026, at 2:04 AM, Jonathan Grant via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>> I usually use for very straight-forward things, like array access index bounds checks, or nullptr.
>>
>> If this is the main application area, I really don’t see the advantage over contracts. In many cases the compiler can (could?) be able to prove that the contract is always fulfilled and eliminate the check when optimization is turned on. So, it works the same if it can be proven (no runtime performance overhead). Where contracts and compile_assert differ is in cases where it cannot be proven. Contracts will just leave the check in and compile_assert refuses to compile. Outside of embedded systems I expect programmers to prefer contracts: an occasional overhead doesn’t hurt too much and I’d rather have my software working with this little overhead than having to fight a checker. Standard library hardening has shown in large projects that usually the overhead of contracts is negligible.
>>
>
> May I ask, is that C++ standard library hardening at runtime or compile time?
> My personal preference would be to add a compile_assert(str != nullptr) on std::string() to prevent a nullptr ever be passed in. It still crashed last time I checked it. It did come up in a safety critical system, these nullptr do sneak through occasionally, and once is enough to crash.
Contracts have different modes: Checks can be disabled at runtime and handling can be different. This is what others have already suggested: Add yet another mode to contracts that does compile time checking and fails at compile time (or provides a diagnostic). This would be a compiler flag. So, with the correct (new) mode there wouldn’t be any runtime errors because of contracts. I believe there is also discussion about annotating individual contract conditions/assertions to allow for different modes in the same compilation unit. In this way contracts could be used for hard compile time enforcement.
>
>> On the other hand, this is a strong point to make compile_assert an option for contract enforcement. However, this means that we would need a way to skip proving to make our program compile. Maybe we can add an attribute [[no_contract_proof]] (I couldn’t quickly come up with a better name) to function calls where we don’t want a compile time check of the pre condition. Or we can have a contract_assume() that only makes assumptions for contract proving, but has no influence on optimizations like [[assume()]]. (Though the regular [[assume()]] can be used by contract proving as well.)
>
> May I ask if you have an example of the kind of proof that might be tricky to get to pass when compiling? Something that you really need to validate, but at present cannot.
I don‘t use contracts yet, so I don’t have any examples. I‘m thinking about pre and post conditions in the STL: if I turn on your compile time asserts for contracts (if we would follow down this route), the compiler might not be able to prove pre conditions at compile time in every single place. This is why I would think that you need to be able to tell the compiler somehow not to prove it in certain places (trust the programmer!). With your original proposal you just wouldn’t put these checks into the code in the first place (because every check would need to be explicit).
>
> Lastly, may I ask, which is your main compiler?
At work, I‘m using MSVC 2019 and we are still on C++17. For my hobby projects I‘m on macOS with the default XCode compiler. But even there I‘m not using bleeding edge features of C++ to get compatibility for more people (and also because some projects are already a little older and I don‘t have the time to refactor them to include the newest features).
Honestly, I’m probably not going to be a user of your feature (because: reasons…). I‘m just trying to help to think through these features and make them helpful for as many people as possible.
> Kind regards, Jonathan
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> Hello Simon
>
> Many thanks for reviewing P4021.
>
>> On 07/03/2026 06:24, Simon Schröder via Std-Proposals wrote:
>>
>>
>>>> On Mar 5, 2026, at 2:04 AM, Jonathan Grant via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>> I usually use for very straight-forward things, like array access index bounds checks, or nullptr.
>>
>> If this is the main application area, I really don’t see the advantage over contracts. In many cases the compiler can (could?) be able to prove that the contract is always fulfilled and eliminate the check when optimization is turned on. So, it works the same if it can be proven (no runtime performance overhead). Where contracts and compile_assert differ is in cases where it cannot be proven. Contracts will just leave the check in and compile_assert refuses to compile. Outside of embedded systems I expect programmers to prefer contracts: an occasional overhead doesn’t hurt too much and I’d rather have my software working with this little overhead than having to fight a checker. Standard library hardening has shown in large projects that usually the overhead of contracts is negligible.
>>
>
> May I ask, is that C++ standard library hardening at runtime or compile time?
> My personal preference would be to add a compile_assert(str != nullptr) on std::string() to prevent a nullptr ever be passed in. It still crashed last time I checked it. It did come up in a safety critical system, these nullptr do sneak through occasionally, and once is enough to crash.
Contracts have different modes: Checks can be disabled at runtime and handling can be different. This is what others have already suggested: Add yet another mode to contracts that does compile time checking and fails at compile time (or provides a diagnostic). This would be a compiler flag. So, with the correct (new) mode there wouldn’t be any runtime errors because of contracts. I believe there is also discussion about annotating individual contract conditions/assertions to allow for different modes in the same compilation unit. In this way contracts could be used for hard compile time enforcement.
>
>> On the other hand, this is a strong point to make compile_assert an option for contract enforcement. However, this means that we would need a way to skip proving to make our program compile. Maybe we can add an attribute [[no_contract_proof]] (I couldn’t quickly come up with a better name) to function calls where we don’t want a compile time check of the pre condition. Or we can have a contract_assume() that only makes assumptions for contract proving, but has no influence on optimizations like [[assume()]]. (Though the regular [[assume()]] can be used by contract proving as well.)
>
> May I ask if you have an example of the kind of proof that might be tricky to get to pass when compiling? Something that you really need to validate, but at present cannot.
I don‘t use contracts yet, so I don’t have any examples. I‘m thinking about pre and post conditions in the STL: if I turn on your compile time asserts for contracts (if we would follow down this route), the compiler might not be able to prove pre conditions at compile time in every single place. This is why I would think that you need to be able to tell the compiler somehow not to prove it in certain places (trust the programmer!). With your original proposal you just wouldn’t put these checks into the code in the first place (because every check would need to be explicit).
>
> Lastly, may I ask, which is your main compiler?
At work, I‘m using MSVC 2019 and we are still on C++17. For my hobby projects I‘m on macOS with the default XCode compiler. But even there I‘m not using bleeding edge features of C++ to get compatibility for more people (and also because some projects are already a little older and I don‘t have the time to refactor them to include the newest features).
Honestly, I’m probably not going to be a user of your feature (because: reasons…). I‘m just trying to help to think through these features and make them helpful for as many people as possible.
> Kind regards, Jonathan
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2026-03-14 09:58:48