C++ template parameter constraints

C++ template parameter constraints

[Martin Buchholz]

If you are interested in C++ template hacking or the C++ compile-time
reflection branch, then you may want to read my web page on template
parameter constraints:

http://m17n.org/martin/writings/template-parameter-constraints.html

(feedback desired)

Obgcc:
Nathan fixed the following bug

c++/9053: g++ confused about ambiguity of overloaded function templates

Basically, g++ used to consider the following overloaded function
templates ambiguous.

template <class T> typename bar<T>::type foo (T);
template <class T> typename qux<T>::type foo (T);

This has now been fixed in g++ 3.3 (thanks Nathan), but what about
earlier versions?

Here I'd like to point out the following workaround for gcc 3.2:

namespace Dummy1 { template <class T> typename bar<T>::type foo (T); }
namespace Dummy2 { template <class T> typename qux<T>::type foo (T); }
using Dummy1::foo;
using Dummy2::foo;

This is described in greater detail at the above web page.

Martin

Re: C++ template parameter constraints

[Alexandre Oliva]

On Jan 30, 2003, Martin Buchholz <martin@xemacs.org> wrote:

> http://m17n.org/martin/writings/template-parameter-constraints.html

> (feedback desired)

/me thinks the syntax for satisfying might be something like Modula3's
`T1 < T2' constraint, used to indicate that type T1 must be the same
or derived from T2.  We could use something like:

template <class T : predicate<T>::satisfied> declaration;

and then define the predicate template in such a way that satisfied is
typedefed to T if T satisfies the predicate, and not defined at all
otherwise.


Another addition that I'd find useful for template meta-programming is
an operator such as :?:, similar to :: but with the following
additional properties:

- its left-hand operand must be a template-dependent type name

- if the address of an expression containing :?: is taken and it turns
  out that, for a particular instantiation of the template, the member
  does not exist, the result is NULL

- a typename expression containing :?: that refers to a type member
  that does not exist in a given template name resolves to a new C++
  type that, in the absence of a better name, will be called
  nosuchtype.

  - sizeof applied to nosuchtype is zero

  - Any typename expression referencing members of nosuchtype resolve
  to nosuchtype

  - Any expression involving data members of nosuchtype has type
  nosuchtype, and translates to a call of terminate()

  - Any expression involving function members of nosuchtype (operator
  functions included) succeed overload resolution, but performing the
  actual function call evaluates the arguments and calls terminate().

  The idea is that such constructs be guarded by NULL- or zero-size
  tests and be optimized away, but still parse correctly.

Comments?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: C++ template parameter constraints

[Gabriel Dos Reis]

Alexandre Oliva <aoliva@redhat.com> writes:

| On Jan 30, 2003, Martin Buchholz <martin@xemacs.org> wrote:
| 
| > http://m17n.org/martin/writings/template-parameter-constraints.html
| 
| > (feedback desired)
| 
| /me thinks the syntax for satisfying might be something like Modula3's
| `T1 < T2' constraint, used to indicate that type T1 must be the same
| or derived from T2.  We could use something like:
| 
| template <class T : predicate<T>::satisfied> declaration;

This has been hashed several times (on the C++ committee reflectors,
at ACCU Spring conferences, with Bjarne Stroustrup, Jeremy Siek,
Fergus Henderson and many others)...  
The above doesn't scale to constraints on seperately declared
template-parameters.  The last syntaxes Bjarne Stroustrup discussed
were about

  template<class T, class U> [predicate<T, V>::holds]
    declaration;

Note where the constraints goes (in the square brackets just after the
template-parameters declaration).  The above does not conflict with
current grammar, allows for separately declared template-parameters
and works smoothly with other template meta-programming features.

[...]

| Comments?

I'll make more once I'm finished with 3.2.2 issues :-)

-- Gaby

Re: C++ template parameter constraints

[Martin Buchholz]

>>>>> "A" == Alexandre Oliva <aoliva@redhat.com> writes:

A> On Jan 30, 2003, Martin Buchholz <martin@xemacs.org> wrote:
>> http://m17n.org/martin/writings/template-parameter-constraints.html

>> (feedback desired)

A> /me thinks the syntax for satisfying might be something like Modula3's
A> `T1 < T2' constraint, used to indicate that type T1 must be the same

As I say elsewhere, I don't like `T1 < T2' because I would like to
express arbitrary compile-time constraints.

A> or derived from T2.  We could use something like:

A> template <class T : predicate<T>::satisfied> declaration;

I don't think the constraint belongs within the <...> template
parameter list, because the constraints apply potentially to ALL the
template parameters, i.e. a template constraint may not be naturally
associated with a particular template parameter.  Standard example is
again `T1 is a subclass of T2'.

A> and then define the predicate template in such a way that satisfied is
A> typedefed to T if T satisfies the predicate, and not defined at all
A> otherwise.

Yes.

A> Another addition that I'd find useful for template meta-programming is
A> an operator such as :?:, similar to :: but with the following
A> additional properties:

A> - its left-hand operand must be a template-dependent type name

A> - if the address of an expression containing :?: is taken and it turns
A>   out that, for a particular instantiation of the template, the member
A>   does not exist, the result is NULL

I would prefer a more general solution.  I imagine a C++ compile-time
function something like

is_compilable<Type, ...> ({ declarations ... ;;; code ... })

You could then ask

is_compilable<T> ({ T x; T y ;;;  x < y;    })
is_compilable<T> ({ T x; T y ;;;  x == y;   })
is_compilable<T> ({ T x;     ;;;  hash (x); })

to decide at compile time whether to use a linked list, a binary tree,
or a hash table to implement a `set<T>' data type, without the user
having to create a special traits class to help out.

A> - a typename expression containing :?: that refers to a type member
A>   that does not exist in a given template name resolves to a new C++
A>   type that, in the absence of a better name, will be called
A>   nosuchtype.

A>   - sizeof applied to nosuchtype is zero

A>   - Any typename expression referencing members of nosuchtype resolve
A>   to nosuchtype

A>   - Any expression involving data members of nosuchtype has type
A>   nosuchtype, and translates to a call of terminate()

A>   - Any expression involving function members of nosuchtype (operator
A>   functions included) succeed overload resolution, but performing the
A>   actual function call evaluates the arguments and calls terminate().

A>   The idea is that such constructs be guarded by NULL- or zero-size
A>   tests and be optimized away, but still parse correctly.

A> Comments?

Compile-time reflection in C++ is incredibly useful, as is shown by
the enormous efforts being applied to implement and use it.  The C++
committee has to recognize that C++ is now a language with a
compile-time MOP, like OpenC++.  But the current MOP is limited and
amazingly kludgy.  A small number of extensions to C++ can probably
fix that.  Finding the appropriate extensions to enable that will be
difficult.

Being able to ask the compiler whether a piece of code is compilable
might be a generalization of your idea above.  Of course, if you
introduce something like is_compilable, people will want to
distinguish among different kinds of compile failures.

Currently, boost's is_base_and_derived causes a compile error if
private inheritance is used.  Implementors of is_base_and_derived
would want to have something like is_compilable, but they might also
want to know WHY something is or is not compilable.