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.

### 1105. Shouldn't `Range` be an `auto concept`

Section: 99 [iterator.concepts.range] Status: NAD Concepts Submitter: David Abrahams Opened: 2009-04-23 Last modified: 2016-01-28

Priority: Not Prioritized

View all issues with NAD Concepts status.

Discussion:

[ 2009-04-26 Herb adds: ]

> Here's a common example: We have many ISV customers who have built lots of in-house STL-like containers. Imagine that, for the past ten years, the user has been happily using his `XYZCorpContainer<T>` that has `begin()` and `end()` and an iterator typedef, and indeed satisfies nearly all of `Container`, though maybe not quite all just like `valarray`. The user upgrades to a range-enabled version of a library, and now `lib_algo( xyz.begin(), xyz.end());` no longer works -- compiler error.

> Even though `XYZCorpContainer` matches the pre-conceptized version of the algorithm, and has been working for years, it appears the user has to write at least this:

> >     template<class T> concept_map Range<XYZCorpContainer<T>> {};

> >     template<class T> concept_map Range<const XYZCorpContainer<T>> {};

> Is that correct?

> But he may actually have to write this as we do for initializer list:

> >     template<class T>
> >     concept_map Range<XYZCorpContainer<T>> {
> >        typedef T* iterator;
> >        iterator begin(XYZCorpContainer<T> c) { return c.begin(); }
> >        iterator end(XYZCorpContainer<T> c) { return c.end(); }
> >     };

> >     template<class T>
> >     concept_map Range<const XYZCorpContainer<T>> {
> >        typedef T* iterator;
> >        iterator begin(XYZCorpContainer<T> c) { return c.begin(); }
> >        iterator end(XYZCorpContainer<T> c) { return c.end(); }
> >     };

[ 2009-04-28 Alisdair adds: ]

> I recommend NAD, although remain concerned about header organisation.

> A user container will satisfy the `MemberContainer` concept, which IS auto. There is a concept_map for all `MemberContainers` to `Container`, and then a further concept_map for all `Container` to `Range`, so the stated problem is not actually true. User defined containers will automatically match the `Range` concept without explicitly declaring a concept_map.

> The problem is that they should now provide an additional two headers, `<iterator_concepts>` and `<container_concepts>`. The only difference from making `Range` an auto concept would be this reduces to a single header, `<iterator_concepts>`.

> I am strongly in favour of any resolution that tackles the issue of explicitly requiring concept headers to make these concept maps available.

[ Batavia (2009-05): ]

> We observe there is a recent paper by Bjarne that overlaps this issue.

> Alisdair continues to recommend NAD.

> Move to Open, and recommend the issue be deferred until after the next Committee Draft is issued.

Proposed resolution: