That's the Jeopardy answer.
From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of Julien Villemure-Fréchette via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Tuesday, August 5, 2025 6:57:45 PM
To: std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>
Cc: Julien Villemure-Fréchette <julien.villemure@hotmail.com>
Subject: Re: [std-proposals] Standardising 0xdeadbeef for pointers
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@lists.isocpp.org> 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?