This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD Concepts status.

### 1080. Concept ArithmeticLike should provide explicit boolean conversion

Section: 99 [concept.arithmetic] Status: NAD Concepts Submitter: Daniel Krügler Opened: 2009-03-21 Last modified: 2016-01-28

Priority: Not Prioritized

View all issues with NAD Concepts status.

Discussion:

Astonishingly, the current concept ArithmeticLike as specified in 99 [concept.arithmetic] does not provide explicit conversion to `bool` although this is a common property of arithmetic types (7.3.15 [conv.bool]). Recent proposals that introduced such types (integers of arbitrary precision, n2143, decimals n2732 indirectly via conversion to `long long`) also took care of such a feature.

Adding such an explicit conversion associated function would also partly solve a currently invalid effects clause in library, which bases on this property, 25.3.5.7 [random.access.iterators]/2:

>     { difference_type m = n;
>      if (m >= 0) while (m--) ++r;
>      else while (m++) --r;
>      return r; }

Both while-loops take advantage of a contextual conversion to `bool` (Another problem is that the >= comparison uses the no longer supported existing implicit conversion from `int` to `IntegralLike`).

Original proposed resolution:

1. In 99 [concept.arithmetic], add to the list of less refined concepts one further concept:

   >     concept ArithmeticLike<typename T>
   >       : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>,
   >         HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>,
   >         HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>,
   >         HasPostdecrement<T>,
   >         HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>,
   >         HasMultiplyAssign<T, const T&>,
   >         HasDivideAssign<T, const T&>, ExplicitlyConvertible<T, bool> {

2. In 25.3.5.7 [random.access.iterators]/2 change the current effects clause as indicated [The proposed insertion fixes the problem that the previous implicit construction from integrals has been changed to an explicit constructor]:

   >     { difference_type m = n;
   >      if (m >= difference_type(0)) while (m--) ++r;
   >      else while (m++) --r;
   >      return r; }

[ Batavia (2009-05): ]

> We agree that arithmetic types ought be convertible to `bool`, and we therefore agree with the proposed resolution's paragraph 1.

> We do not agree that the cited effects clause is invalid, as it expresses intent rather than specific code.

> Move to Review, pending input from concepts experts.

Proposed resolution:

In 99 [concept.arithmetic], add to the list of less refined concepts one further concept:

>     concept ArithmeticLike<typename T>
>       : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>,
>         HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>,
>         HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>,
>         HasPostdecrement<T>,
>         HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>,
>         HasMultiplyAssign<T, const T&>,
>         HasDivideAssign<T, const T&>, ExplicitlyConvertible<T, bool> {