Date: Sun, 27 Apr 2025 06:55:06 +0200
The issue with the proposal is that many functions exist that don't throw
but aren't marked noexcept, or which only throw under circumstances that
you don't trigger. For example, the callee can throw on failed bounds
checks, but the caller makes sure that indices are within bounds.
Personally, I only use noexcept when a function has a wide contract, i.e.
it succeeds no matter what, with no preconditions/assertions.
noexcept(explicit) would be pretty much useless to me.
Also note that the usefulness of noexcept is dramatically overstated by
some developers. You should probably pay attention to it on special member
functions, swap(), and a few other key functions, but it has virtually no
impact anywhere else.
> I fed my idea in ChatGPT and asked it to produce one concise paragraph
> describing the benefits this new feature could bring, and it gave me
> back:
I'm not going to read that AI slop. Is this some out-of-season April Fool's
joke?
but aren't marked noexcept, or which only throw under circumstances that
you don't trigger. For example, the callee can throw on failed bounds
checks, but the caller makes sure that indices are within bounds.
Personally, I only use noexcept when a function has a wide contract, i.e.
it succeeds no matter what, with no preconditions/assertions.
noexcept(explicit) would be pretty much useless to me.
Also note that the usefulness of noexcept is dramatically overstated by
some developers. You should probably pay attention to it on special member
functions, swap(), and a few other key functions, but it has virtually no
impact anywhere else.
> I fed my idea in ChatGPT and asked it to produce one concise paragraph
> describing the benefits this new feature could bring, and it gave me
> back:
I'm not going to read that AI slop. Is this some out-of-season April Fool's
joke?
Received on 2025-04-27 04:55:24