This raises an an important issue for implementing a "throw_on_nullptr" function: you may only call functions marked with "throw_on_nullptr" within such a function. This limits you to use only APIs that has functions marked as such. To be able to call a function not marked with "throw_on_nullptr", you would still need to ensure (either manually or from invariants implied from source code) that this function is called in contact, and that it wouldn't evaluate an access through a null pointer value, and if it would evaluate through a null pointer value, then manually throw before attempting to call it. Even then, the function could have a bug and actually evaluate an access through a null pointer value even when called in contract, in which case the function would not be throwing an exception and you would end up violating the "throw_on_nullptr" speciation: this would in itself lead to a UB, on top a the UB of evaluating the access through the null pointer value.

On August 3, 2025 10:48:08 a.m. EDT, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>I'm going off on a tangent here, but imagine if we could mark a function
>(or lambda) as follows:
>
> int Func(double) throw_on_nullptr
> {
> . . .
> }
>
>If you try to dereference a nullptr in this function, or if you perform
>addition or subtraction on a nullptr, it throws std::nullptr_t.
>
>Maybe?
>
>
>
>
>
>>