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.
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, 24.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:
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> {
In 24.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> {