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; }