Date: Tue, 15 Sep 2026 10:55:25 -0700
On Tuesday, 15 September 2026 05:01:09 Pacific Daylight Time Frederick
Virchanza Gotham via Std-Proposals wrote:
> What complicates this significantly, as you mentioned, is the Lakos
> rule -- i.e. "The throwing of an exception is an acceptable form of
> undefined behaviour". But given the Lakos rule, should "std::sqrt" be
> defined as follows?
>
> double sqrt(double) noexceptLakos;
>
> I'm saying, should we have a new
> marker/identifier/keyword/annotation/attribute to indicate that a
> function won't throw so long as you don't invoke UB?
No, not for UB, as others have said.
But UB is not the problem. sqrt() does not have a UB problem - it has a narrow
contract (domain of operation) and, if you violate it, it has a deterministic
way of reporting the error.
Other functions with narrow contract may not have such a deterministic way and
may have undefined behaviour. The argument for the Lakos rule (as I understand
it) is that one may want to change the implementation to detect such
conditions and report them via exceptions - something a contact precondition
could do.
Either way, the point is that functions may fail to have the noexcept marker
for any number of reasons and yet never throw under the conditions that the
caller has arranged.
Virchanza Gotham via Std-Proposals wrote:
> What complicates this significantly, as you mentioned, is the Lakos
> rule -- i.e. "The throwing of an exception is an acceptable form of
> undefined behaviour". But given the Lakos rule, should "std::sqrt" be
> defined as follows?
>
> double sqrt(double) noexceptLakos;
>
> I'm saying, should we have a new
> marker/identifier/keyword/annotation/attribute to indicate that a
> function won't throw so long as you don't invoke UB?
No, not for UB, as others have said.
But UB is not the problem. sqrt() does not have a UB problem - it has a narrow
contract (domain of operation) and, if you violate it, it has a deterministic
way of reporting the error.
Other functions with narrow contract may not have such a deterministic way and
may have undefined behaviour. The argument for the Lakos rule (as I understand
it) is that one may want to change the implementation to detect such
conditions and report them via exceptions - something a contact precondition
could do.
Either way, the point is that functions may fail to have the noexcept marker
for any number of reasons and yet never throw under the conditions that the
caller has arranged.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-09-15 17:55:40
