Just to make my statement:

Those functions use their return value to do error reporting. I would be shocked about a design that additionally would throw exceptions.

And they pretend to be low level.

Should I file a library issue to make them noexcept. Or is that too much of Design that lewg needs to be involved?

Regards
Peter

sent from a mobile device so please excuse strange words due to autocorrection.
Peter Sommerlad
peter.cpp_at_[hidden]
+41-79-432 23 32

> On 15 Jul 2020, at 13:16, Daniel Krügler <daniel.kruegler_at_[hidden]> wrote:
>
> Am Mi., 15. Juli 2020 um 11:18 Uhr schrieb Peter Sommerlad (C++) via
> Std-Discussion <std-discussion_at_[hidden]>:
>>
>> Hi,
>>
>> while looking at <charconv> I was wondering why the from_chars() and
>> to_chars() are not noexcept. I understand that noexcept might lead to
>> worse code generation because of std::terminate() might need to be called.
>>
>> Is that the sole reason for not making those functions noexcept(true) ?
>>
>> TIA & Stay Healthy & Regards
>> Peter.
>> --
>> Peter Sommerlad
>
> Giuseppe already pointed the reason out, but let me extend a bit on
> that: Our historic agreement and policy were that functions should be
> only marked as (unconditionally) noexcept, when they have a wide
> contract (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf).
> The idea for this policy was that for such a function the
> implementation should decide whether it will mark that function as
> noexcept or not to provide for implementation freedom how to handle
> precondition violations. This was never a strict, binding rule,
> because we always have allowed exceptions of that rule, e.g. if we
> considered specific functions as sufficiently low-level we sometimes
> declared the relevant functions as noexcept regardless, but pointed
> that deviation out (at least during discussions).
>
> We recently questioned the strict interpretation of the convention
> described by N3279 a bit, because we have now years of practical
> experience with noexcept, and that should make it at least a bit
> easier to question some historic decisions by "narrowing-down" to a
> concrete unconditional noexcept specifier. If there exists evidence
> for a good candidate to specify noexcept even in the presence of
> narrowing contracts, this should be handled by an LWG issue.
>
> Thanks,
>
> - Daniel