Date: Sat, 10 May 2025 12:40:16 +0200
It seems that people have already forgotten: C++ used to have a way to mark functions that are not noexcept: ‘throw’. It turned out that programmers were now good at providing this information which is why we now annotate functions the other way around. Marking functions as throwing was so unpopular that this feature was deprecated in C++11 and removed in C++17 (https://en.cppreference.com/w/cpp/language/except_spec).
Concerning C functions: Would it make sense to automatically declare all ‘extern “C”’ functions noexcept? Or is this something that is already allowed for compilers to assume? It might be a bad idea if someone provides a C interface for a C++ implementation, though.
> On May 9, 2025, at 9:41 AM, Filip via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Just a thought but I would like to have some level of mandatory usage of noexcept.
>
> Why isn’t it mandatory to mark function that has throw statement with noexcept(false)?
> Then it would be very clear what to look for.
>
> I would like to be explicit with maybe try keyword that could be used to mark a function that throws as automatically rethrowing.
> In my experience it would greatly reduce the time it takes to look for exception handling.
>
> Cheers, Filip
>
>>> Wiadomość napisana przez Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> w dniu 6 maj 2025, o godz. 20:56:
>>>
>> On Tuesday, 6 May 2025 02:54:32 Pacific Daylight Time Frederick Virchanza
>> Gotham via Std-Proposals wrote:
>>> 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".
>>
>> Or:
>>
>> return [&]() noexcept { return strlen(p); }();
>>
>> Let's not reinvent the wheel if already have a solution, albeit with a small
>> syntax cost. This also removes the need to capture an overload set for the
>> cast operator.
>>
>> And you should really complain to your C library and have them add the
>> noexcept markers. It's QoI. glibc has the marker there for strlen, so for all
>> I care the problem is solved and every other implementation out there is
>> simply behind the state of the art.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Principal Engineer - Intel DCAI Platform & System Engineering
>>
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Concerning C functions: Would it make sense to automatically declare all ‘extern “C”’ functions noexcept? Or is this something that is already allowed for compilers to assume? It might be a bad idea if someone provides a C interface for a C++ implementation, though.
> On May 9, 2025, at 9:41 AM, Filip via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Just a thought but I would like to have some level of mandatory usage of noexcept.
>
> Why isn’t it mandatory to mark function that has throw statement with noexcept(false)?
> Then it would be very clear what to look for.
>
> I would like to be explicit with maybe try keyword that could be used to mark a function that throws as automatically rethrowing.
> In my experience it would greatly reduce the time it takes to look for exception handling.
>
> Cheers, Filip
>
>>> Wiadomość napisana przez Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> w dniu 6 maj 2025, o godz. 20:56:
>>>
>> On Tuesday, 6 May 2025 02:54:32 Pacific Daylight Time Frederick Virchanza
>> Gotham via Std-Proposals wrote:
>>> 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".
>>
>> Or:
>>
>> return [&]() noexcept { return strlen(p); }();
>>
>> Let's not reinvent the wheel if already have a solution, albeit with a small
>> syntax cost. This also removes the need to capture an overload set for the
>> cast operator.
>>
>> And you should really complain to your C library and have them add the
>> noexcept markers. It's QoI. glibc has the marker there for strlen, so for all
>> I care the problem is solved and every other implementation out there is
>> simply behind the state of the art.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Principal Engineer - Intel DCAI Platform & System Engineering
>>
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-05-10 10:40:31