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: