Title
bool can't be an integer-like type
Status
ready
Section
[iterator.concept.winc]
Submitter
Casey Carter

Created on 2020-07-23.00:00:00 last changed yesterday

Messages

Date: 2020-08-02.18:23:26

Proposed resolution:

This wording is relative to N4861.

  1. Modify [iterator.concept.winc] as indicated:

    -11- A type I other than cv bool is integer-like if it models integral<I> or if it is an integer-class type. An integer-like type I is signed-integer-like if it models signed_integral<I> or if it is a signed-integer-class type. An integer-like type I is unsigned-integer-like if it models unsigned_integral<I> or if it is an unsigned-integer-class type.

Date: 2020-08-15.00:00:00

[ 2020-08-02; Reflector prioritization ]

Set priority to 0 and status to Tentatively Ready after six votes in favour during reflector discussions.

Date: 2020-07-23.00:00:00

Per [ranges.syn]/1, the Standard Library believes it can convert an integer-like type X to an unsigned integer-like type with the exposition-only type alias make-unsigned-like-t. make-unsigned-like-t<X> is specified as being equivalent to make_unsigned_t<X> when X is an integral type. However, despite being an integral type, bool is not a valid template type argument for make_unsigned_t per [tab:meta.trans.sign].

This problem with bool was an oversight when we added support for integer-like types: it was certainly not the design intent to allow ranges::size(r) to return false! While we could devise some more-complicated metaprogramming to allow use of bool, it seems easier — and consistent with the design intent — to simply exclude bool from the set of integer-like types.

History
Date User Action Args
2020-08-02 18:23:26adminsetmessages: + msg11428
2020-08-02 18:23:26adminsetstatus: new -> ready
2020-07-26 13:09:12adminsetmessages: + msg11414
2020-07-23 00:00:00admincreate