On Mon, May 5, 2025 at 3:02 PM Jason McKesson wrote:
>
> The context of this conversation is such that `noexcept` has a
> (completely) different meaning than it currently has. The OP wants the
> compiler to statically verify that no exception throwing happens
> *within* a `noexcept` function, not merely that the function itself
> cannot allow an exception to pass through it. The point of the cast is
> to take a function that isn't marked `noexcept` but will not throw and
> tell the compiler that it's OK to call it in a `noexcept` function
> (because the OP wants calls to non-noexcept functions to give an
> error).


Yes that's exactly what I'm getting at. So let's say we have a
function that returns the amount of bytes of memory required to
duplicate a string:

    size_t bytes_needed(char const *const p)
    {
        if ( nullptr == p ) return 0uz;
        return strlen(p) + 1uz;
    }

So now let's make it noexcept(explicit):

    size_t bytes_needed(char const *const p) noexcept(explicit)
    {
        if ( nullptr == p ) return 0uz;
        return strlen(p) + 1uz;
    }

Now we get a compiler error because we call a "noexcept(false)"
function from within a "noexcept(explicit)" function. So In order to
get this to compile, we would do something like:

    size_t bytes_needed(char const *const p) noexcept(explicit)
    {
        if ( nullptr == p ) return 0uz;
        return noexcept_cast<true>(strlen)(p) + 1uz;
    }

That would be one possible use of "noexcept_cast".

Another use might be where we have a class something like:

    class MyClass {
        size_t (*get_len)(char const *) noexcept;
    public:
        void SetLenGetter( size_t (*get_len)(char const *) noexcept );
    };

So we would set the 'getter' as follows:

    obj.SetLenGetter( noexcept_cast<true>( &std::strlen ) );


> Now yes, this is a problem created only by the OP's insistence on
> changing the fundamental meaning of keywords, but that is the core
> context of this conversation.


If I were using the word "noexcept" to mean something like
"non-exceptional mathematical operations", then yeah I'd agree with
you that I'm changing the meaning of the word. But I'm talking about
"no exceptions", so adding the new syntax "noexcept(explicit)" is an
expansion on a previous feature, rather than changing the fundamental
meaning of a keyword.