++(++iter)

Even if I required that ++iter is only convertible to Iter& the double increment expression would not work.

My original concern about the valid expression of OutputIterator (*r = o) is also a bit misplaced. I guess it is more a deficiency in the concept OutputIterator than in concept support itself. Ideally it should be a function output(r, o), but STL concepts like C++ operators so much.

There are other compelling arguments for pseudo-signatures, though. Both approaches have equivalent expressive capability; the difference is in what each one makes easy or hard to express.

For example, pseudo-signatures make it absolutely dead-simple to declare a new model of a concept: you declare a class whose body is the concept body, with a few mechanical changes. With valid expressions, you have to deduce a set of functions and associated types from the expressions.

Valid expressions make it much easier to write constraints that unintentionally lock down the algorithm implementation. You actually have to try constraining a few algorithms to see what happens. So, without peeking ahead, write down the valid-expression constraints for std::find.

Now, is the following be a legal implementation according to your constraints? Should it be legal?

template <InputIterator II, class Value>
requires { … }
II find(II first, II last, Value const& v)
{
    while (first != last)
    {
         II::value_type const& x = *first++;
         if (x == v) break;
    }
    return first;
}

But now, I wonder if this implementation would still be non-conforming if we had C++ concepts that use valid-expressions. If I have a nasty model where the result of operator== has custom operator!:

NastyBool operator==( NastyT, NastyT );
void operator!( NastyBool );

This nasty operator! should not be considered because it would not be visible inside find(). find() only sees my types ‘through’ a concept, so I can only see operator==, but not operator!, so I have to apply the conversion from NastyBool to bool. Or am I wrong?

Would it surprise you to learn that the implementation of find you pasted has been carefully engineered to avoid the problem? The SGI STL implementation (almost certainly identical to the original STL algorithm) was:

template <class _InputIter, class _Tp>
inline _InputIter find(_InputIter __first, _InputIter __last,
                       const _Tp& __val,
                       input_iterator_tag)
{
  while (__first != __last && !(*__first == __val))
    ++__first;
  return __first;
}

Believe it or not, the above is actually a nonconforming implementation! Convertibility to bool of the operator== result is not sufficient to ensure it compiles. I think any system in which the original STL authors would have to struggle to meet their own requirements clauses for something as trivial as find is problematic.

return x < y && random() % 3;

appears to me a non-real-life one. I also read that “Standard library vendors have already had to deal with this problem, e.g., for find.” Could you expand on it a bit more? I have looked at the implementation of find in my STL implementation:

template<class _InIt,
    class _Ty> inline
    _InIt _Find(_InIt _First, _InIt _Last, const _Ty& _Val)
    {   // find first matching _Val
    for (; _First != _Last; ++_First)
        if (*_First == _Val)
            break;
    return (_First);
    }

And it does not appear that the result of operator== that is not bool, but convertible to bool would render a surprising behavior.

I understand that there might be more technical difficulties (or impossibilities) in implementing “valid expressions”, but as the “end consumer” of C++ I find valid expressions simpler in some situations. For instance, if I wanted to write a concept for OutputIterator, I require that the following expression is valid:

*r = o

I do not (want to) care what the result type of operator* is or if assignment returns void or some value. In a constrained function template I will just be putting statements *r = o; and this is all I am asking for.

Regards.

Once the “root” concept is explicit, in most cases it doesn’t require any more concept maps even if all of the more-refined concepts are explicit. This is because of the way we tend to use concept maps: we write one concept map for the most specific concept (e.g., RandomAccessIterator rather than Iterator, BackInsertionContainer rather than Container), and the compiler implicitly generates concept maps for the less-specific concepts.

Rodrigo: Doug came with a rationale on why it wasn’t this way. My opinion is that it was a wrong decision. Other options may exist. For example, we could have: concept, auto concept, explicit concept. http://zone-team.com.mx/temp/c2.cpp summarizes my thoughts.

You can actually get this kind of behavior from the current concepts proposal, by using associated requirements rather than refinement. Check out how the OutputIterator concept is specified, which boils down to this:

concept Iterator<typename Iter> {
  // basic iterator requirements
}
 
auto concept OutputIterator<typename Iter, typename Value> {
  requires Iterator<Iter>;
  // assignability requirements to allow, e.g., *i = value
}

Here, Iterator is an explicit concept, so you need to write a concept map for it (or one of its more-refined concepts, like RandomAccessIterator) to “opt in” to the iterator system. Then, however, you get the OutputIterator concept automatically matched for your iterator types for any Value type that can be assigned to the reference type of the iterator. I think this gives basically the same capability as the non-auto, non-explicit concepts in your example, and it has definitely come in handy in the Standard Library.

Thanks for coming out to share ideas and comments; it’s great to see different perspectives on a feature like Concepts.

I consider ID more convenient than TD. In fact, my full opposition to the “nothing-is-explicit” or the “explicit-refinement-only” alternatives is because they are subsets of the ID in terms of power.

However, I really hate the number of explicit concepts the ID tends to generate. I find the fact that BackInsertionContainer and friends are explicit embarassing considering they are refinements of another explicit concept: Container. If a type is explicitly told to be a Container, they should be able to automatically match the mentioned refinements. If the types are’t Containers, they shouldn’t.

Doug came with a rationale on why it wasn’t this way. My opinion is that it was a wrong decision. Other options may exist. For example, we could have: concept, auto concept, explicit concept. http://zone-team.com.mx/temp/c2.cpp summarizes my thoughts.

The optimal solution is between “too much explicit” and “explicit enough”. And no, TD isn’t “explicit enough”. ID is closer to that lower bound than TD is.

I am sure the decision we reached in Frankfurt was the right one for both C++ and Concepts. And certainly this was not a decision to kill Concepts but to give it more time so that we could produce a well honed feature to include in the release of C++ after C++0x.

Hi Rodrigo,

The question is, in between what and what? It’s very easy to say that the right answer probably lies between two competing points of view, but the proposal that was voted into the WP already has optional implicit matching (auto concepts).

I see. I think the optimal solution may be somewhere between, but it seems it starts getting more complicated (at least without a whole redesign). Thanks for your reply.

And thanks to Dave for fixing my code!