C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Integer overflow arithmetic

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Fri, 16 Feb 2024 09:00:04 +0000
On Thu, 15 Feb 2024, 22:12 Jan Schultke via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

>
> The use of the term "overflow" for "would_cast_overflow" does not make
> sense, at least not in C++. Type conversions in C++ never overflow,
> but they may truncate non-zero bits, or be lossy. This should probably
> be "is_cast_lossless" or something along those lines.
>

Using the term "narrowing" seems appropriate.


> Furthermore, [[nodiscard]] does not belong in the wording. It's
> debatable whether the standard should mandate [[nodiscard]] on
> functions at all. This is not one of the compelling cases like
> std::vector::empty where [[nodiscard]] avoids ambiguity, so I doubt
> this would pass through the committee. The proposal for functions in
> the <bit> header similarly had [[nodiscard]] attributes, which were
> removed during later revisions.
>

Right, leave it to implementers to add where it's relevant, don't waste
committee time adding it to hundreds and hundreds of individual functions.


>
> You can also improve the wording of is_div_defined. You could just use
> a single expression involving the conditional operator, which is
> better than mixing prose and multiple boolean expressions. However, I
> would simply phrase it as:
>
> > Returns: true if dividend / divisor is defined.
>
> You can omit the "false otherwise"; to my knowledge, it's not
> consistently used in the standard and not seen as necessary. I could
> be wrong though and the standard is just inconsistent.
>

The standard is inconsistent. It should say "otherwise, false".

Received on 2024-02-16 09:01:23