TITLE: Template argument constraints

[ The problem statement is heavily edited. -adc ]


PROBLEM: Frederic Guerin <guerin@IRO.UMontreal.CA>

Given the following template function

    template < class T > T max ( T a, T b ) { return a < b ? b : a; }

When the compiler encounters the following

   Apple a, b;
   Apple c = max(a,b);   // ouupps!  operator < ( Apple, Apple ) undefined
   ...
   bool operator < (Apple a, Apple b) { /* some code */ }

it will complain about not finding the definition of
operator < and will refer to the line number where max is defined [...]



RESPONSE: jamshid@ses.com (Jamshid Afshar)

If your compiler doesn't give useful messages, complain to your
compiler writers or switch a better quality compiler.  Even Cfront
gives the useful message:

	"max.cc", line 4: error: bad operands for <:
				const struct Apple < const struct Apple

At least it's as good as the error message it gives in a non-template
max() function.

[...]

... template argument constraints in general have
been discussed often for C++.  See 15.4.1 of Stroustrup's _The Design
and Evolution of C++_ for some possible language extensions for
expressing constraints on template arguments and the problems and
deficiencies associated with them.  Here's a quote from p346:

	If necessary, the notion [of an inline constraints() function]
	could be formalized as a language feature:

	template<class T>
	constraints {
	   T* tp;	  // T must have:
	   B* bp = tp;    //    an accessible base B
	   tp->f();       //    a member function f
	   T a(1);        //    a constructor from int
	   a = *tp;       //    assignment
	   //...
	}
	class X {/*...*/};

	This would allow constraints on template arguments for
	function templates, but I doubt this extension is worthwhile.
	It is, however, the only constraint system I have seen that
	comes close to satisfying my desire not to overconstrain
	template arguments while remaining fully general, reasonably
	terse, comprehensible, and trivial to implement.

IMO the problems associated with lack of constraints is adequately
solved by better implementations.  Template functions should be
expanded early in the compile cycle (preferably only once per build
and immediately at the first instantiation of a template with
particular template arguments).  Any error messages should be readable
and complete (eg, "List<T,Arena>::sort() expects to use operator < on
T objects at line ...").  Class writers should do a better job of
documenting their expectations of template arguments and test their
templates with the alleged "minimal" classes that satisfy their
documented constraints.