🚀 go-pugleaf

In article <31741E6C.53CA@cs.tu-berlin.de> Roman Lechtchinsky
<wolfro@cs.tu-berlin.de> writes:

> sorry for being curious but I'm only human... My question is: when declaring
> templates, why isn't it required to declare what one expects of the 
> template's parameters? Let's create a template function:
> 
> template<class T> bool equal( const T& t1, const T& t2 )
> {
>   return t1==t2;
> }
> 
> Now, personally I would prefer to write something like:
> 
> template<class T { bool operator==( const T& t ) const; }> ...

Specifying something like this correctly turns out to be extremely
difficult: it's very hard to come up with syntax that neither
overspecifies nor underspecifies the constraints.  In this particular
case, for example: do you really care whether operator== takes a const
T&, as opposed to a T?  Does it matter that it returns bool, instead
of something (like int) that is freely convertable to bool?  Does it
matter whether this is T::operator==(T), or ::operator==(T,T), or any
of a dozen other minor variations?

More realistic cases are even harder to deal with.  Consider, for
example, the for_each algorithm from STL:
template <class InputIterator, class Function>
Function for_each(InputIterator first, InputIterator last, Function f) {
    while (first != last) f(*first++);
    return f;
}

The constraints are as follows:
  There must be either a built-in operator!=, or a global operator!=,
    or a member function InputIterator::operator!=, such that applying
    operator!= to two InputIterators is well-defined and yields something
    that's convertable to bool.
  Operators ++ and * are defined such that *InputIterator++ yields an
    rvalue of some type.
  An object of type Function has an operator() that takes an argument
    of the type returned by *InputIterator++, or at least a type to
    which the return value of *InputIterator++ can be converted.
    The return value of operator() is unimportant.

Notice what's tricky here: the important constraints are relationships
between different types, some of which (like the return value of
InputIterator++, and the return value of *InputIterator++) aren't
named as template parameters.  This rapidly becomes a problem in 
formal specification.

This issue is something that has been thought about, and there's some
discussion of it in D&E.
-- 
Matt Austern
SGI: MTI Compilers Group
austern@isolde.mti.sgi.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]