Proposed resolution:

1. Modify the section [template.bitset] <bitset> synopsis by adding the following at the end of the synopsis:

   
   // XX.X.X bitset range access [bitset.range]
   template<size_t N> unspecified-1 begin(bitset<N>&);
   template<size_t N> unspecified-2 begin(const bitset<N>&);
   template<size_t N> unspecified-1 end(bitset<N>&);
   template<size_t N> unspecified-2 end(const bitset<N>&);
   
   

2. Add a new section "bitset range access" [bitset.range] after the current section [bitset.operators] with the following series of paragraphs:

   1. In the begin and end function templates that follow, unspecified-1 is a type that meets the requirements of a mutable random access iterator ([random.access.iterators]) whose value_type is bool and whose reference type is bitset<N>::reference. unspecified-2 is a type that meets the requirements of a constant random access iterator ([random.access.iterators]) whose value_type is bool and whose reference type is bool.

   
   template<size_t N> unspecified-1 begin(bitset<N>&);
   template<size_t N> unspecified-2 begin(const bitset<N>&);
   
   

   2. Returns: an iterator referencing the first bit in the bitset.

   
   template<size_t N> unspecified-1 end(bitset<N>&);
   template<size_t N> unspecified-2 end(const bitset<N>&);
   

   3. Returns: an iterator referencing one past the last bit in the bitset.

Rationale:

All concepts-related text has been removed from the draft.

[ 2017-06-02 Issues Telecon ]

Resolve as NAD

[ 2017-02 in Kona, LEWG recommends NAD ]

There are better APIs for bits coming, and seems to be consensus in LEWG not to polish bitset any further.

[ 2009-10 post-Santa Cruz: ]

Mark as Tentatively NAD Future due to the loss of concepts.

[ 2009-07-24 Daniel modifies the proposed wording for non-concepts. ]

[ 2009-05-25 Alisdair adds: ]

I just stumbled over the Range concept_map for valarray and this should probably set the precedent on how to write the wording.

Howard: I've replaced the proposed wording with Alisdair's suggestion.

[ Batavia (2009-05): ]

Move to Open. We further recommend this be deferred until after the next Committee Draft.

std::bitset is a homogeneous container-like sequence of bits, yet it does not model the Range concept so cannot be used with the new for-loop syntax. It is the only such type in the library that does NOT support the new for loop.

The obvious reason is that bitset does not support iterators.

At least two reasonable solutions are available:

1. Add an iterator interface to bitset, bringing its interface close to that of std::array
2. Provide an unspecified concept_map for Range<bitset>.

The latter will still need some kind of iterator-like adapter for bitset, but gives implementers greater freedom on the details. E.g. begin/end return some type that simply invokes operator[] on the object it wraps, and increments its index on operator++. A vendor can settle for InputIterator support, rather than wrapping up a full RandomAccessIterator.

I have a mild preference for option (ii) as I think it is less work to specify at this stage of the process, although (i) is probably more useful in the long run.

Hmm, my wording looks a little woolly, as it does not say what the element type of the range is. Do I get a range of bool, bitset<N>::reference, or something else entirely?

I guess most users will assume the behaviour of reference, but expect to work with bool. Bool is OK for read-only traversal, but you really need to take a reference to a bitset::reference if you want to write back.