Proposed resolution:

In [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> {

[ 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.

Astonishingly, the current concept ArithmeticLike as specified in [concept.arithmetic] does not provide explicit conversion to bool although this is a common property of arithmetic types ([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, [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 [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 [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; }