I would like to propose the following changes to the C++ Standard,
the goal of which are to provide an improved ability to specify
the constraints on type parameters to templates.  Let me say  from
the start that my knowledge of compiler implementation is very
limited.  Therefore, my suggestions may have to be rejected
because they are difficult or impossible to implement.

The proposal is based on the concept of "type similarity".  Type
A is said to be similar to type B if any usage of B is a valid
usage of A, and any usage of an instance of B is also a valid
usage of an instance of A.  I suggest that the language be
amended to allow type parameters to templates to be required
to be similar to a previously declared class.  The proposed
new syntax is show in this example:

template <typename A ~ class B>
class X
   {
   ...
   };

Class B must have been declared, but it may or may not be
completely defined in the program.

One obvious shortcoming of this idea is illustrated by
the template:

template <typename A>
class X
   {
   public:

     static int foobar(A &a)
       { return(a.foo(a.bar())); }
   };

A constraint on A is that A::bar() must return the same
type as the parameter to A::foo().  But requiring A to
be similar to a specific type would "over-constrain"
A::bar() to return and A::foo() to receive a specific
type.  Therefore, I also propose that type parameters
can be constrained to be similar to class templates,
as illustrated by this example:

template <typename T>
class B
   {
   private:
     B();

   public:
     T bar();
     int foo(T t);
   };

template <typename A ~ template <typename T> class B>
class X
   {
   public:

     static int foobar(A &a)
       { return(a.foo(a.bar())); }
   };

A type A is similar to a class template B if there is
an instantiation of B to which A is similar.

It would also be useful if the "implied" parameters
to the contraining template could be used in the
body of the template being declared, allowing
for something like:

template <typename T, typename R>
class B
   {
   private:
     B();

   public:
     T bar();
     R foo(T t);
   };

template <
   typename A ~ template <typename T, typename R> class B>
class X
   {
   public:

     // Return value of foobar is the same as the return value of
     // A::foo(), whatever that may be.
     static R foobar(A &a)
       { return(a.foo(a.bar())); }
   };


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

wkaras@yahoo.com wrote:
> I would like to propose the following changes to the C++ Standard,
> the goal of which are to provide an improved ability to specify
> the constraints on type parameters to templates.  Let me say  from
> the start that my knowledge of compiler implementation is very
> limited.  Therefore, my suggestions may have to be rejected
> because they are difficult or impossible to implement.

I see no reason why the Committee would reject any proposal merely
because it would be difficult or impossible to implement. :)

Before getting the the specifics of your proposal, you should first
describe the problem that you are trying to solve. Anyone evaluating
the proposal is first going to have to agree that there is a real
problem that is motivating this idea.

After describing the problem you should then outline potential
approaches available in C++ today, only to show how each one fails to
solve the problem in a reasonable way. Of course during this stage you
may actually find a reasonable solution, in which case you have no
reason to go any further. After all, if the problem can be resolved
using C++ as it is today, there would be reason to change the language.
The goal here is not to change the language, the goal is to solve a
problem.

Only after you have described the problem and C++'s lack of a
reasonable solution, should you get to your proposal, and how it solves
it.

> The proposal is based on the concept of "type similarity".  Type
> A is said to be similar to type B if any usage of B is a valid
> usage of A, and any usage of an instance of B is also a valid
> usage of an instance of A.  I suggest that the language be
> amended to allow type parameters to templates to be required
> to be similar to a previously declared class.  The proposed
> new syntax is show in this example:

> template <typename A ~ class B>
> class X
>    {
>    ...
>    };
>
> Class B must have been declared, but it may or may not be
> completely defined in the program.

It sounds like the class template X wants to require that for any type
parameter A, class B be convertible to A and A be convertible to class
B.

The std::tr1 type traits library has an is_convertible template that
can be used to test two types for convertibility. Class X could use
this trait to test for "similarity" between class B and type A and on
the basis of the result decide whether to be instantiable or not. (The
template class X could specialize the "false" case with a private
constructor or provide an implemention only for the "true" case).

In any event, without a description of the motivating problem, there is
no reasonable way to evaluate this proposal.

Greg


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Greg wrote:
> wkaras@yahoo.com wrote:
> > I would like to propose the following changes to the C++ Standard,
> > the goal of which are to provide an improved ability to specify
> > the constraints on type parameters to templates.  Let me say  from
> > the start that my knowledge of compiler implementation is very
> > limited.  Therefore, my suggestions may have to be rejected
> > because they are difficult or impossible to implement.
>
> I see no reason why the Committee would reject any proposal merely
> because it would be difficult or impossible to implement. :)
>
> Before getting the the specifics of your proposal, you should first
> describe the problem that you are trying to solve. Anyone evaluating
> the proposal is first going to have to agree that there is a real
> problem that is motivating this idea.
>
> After describing the problem you should then outline potential
> approaches available in C++ today, only to show how each one fails to
> solve the problem in a reasonable way. Of course during this stage you
> may actually find a reasonable solution, in which case you have no
> reason to go any further. After all, if the problem can be resolved
> using C++ as it is today, there would be reason to change the language.
> The goal here is not to change the language, the goal is to solve a
> problem.
>
> Only after you have described the problem and C++'s lack of a
> reasonable solution, should you get to your proposal, and how it solves
> it.

Since I wish to continue to be both employed and married, I cannot
dedicate the time it would take to write a reasonable formal proposal
to the Committee.  I unfortunately cannot even fully comply with
your requests made above.

The template itself is of course a statement of the contraints on
the type parameters to the template.  But I think it's a well known
problem that it's hard for a compiler to emit helpful error messages
without a more concise statement of the constraints.  I believe
there is a technique that involves writing a short member function
that contains all usage of the type parameters in the template.  But
aren't there issues with this approach with avoiding runtime
artifacts?  And, I think my suggestion may permit the compiler to
emit diagnostics indicating that an "is similar to" contraint is
over or under-constraining the type parameter in comparison to
how the definition of the template itself constrains the type
parameter.

If anybody has links to good pages that have detailed discussion
with examples of the "dummy function" approach to type
parameter constraint, please post.

If it's feasable to contrain type parameters with class templates,
and extract implied parameters that can be used in the body of
the template being declared, my guess is that this would prove
to be a very useful capability.

> > The proposal is based on the concept of "type similarity".  Type
> > A is said to be similar to type B if any usage of B is a valid
> > usage of A, and any usage of an instance of B is also a valid
> > usage of an instance of A.  I suggest that the language be
> > amended to allow type parameters to templates to be required
> > to be similar to a previously declared class.  The proposed
> > new syntax is show in this example:
>
> > template <typename A ~ class B>
> > class X
> >    {
> >    ...
> >    };
> >
> > Class B must have been declared, but it may or may not be
> > completely defined in the program.
>
> It sounds like the class template X wants to require that for any type
> parameter A, class B be convertible to A and A be convertible to class
> B.
..

The main reason I chose the term "similar" is so I could recyle the
~ token.  But maybe it's a bad choice because it applies symmetry.
When I say A is similar to B, I'm basically saying that B's public
interface is a subset of A's.  So A being similar to B definitely
doesn't imply that B is similar to A.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

wkaras@yahoo.com wrote:
> I would like to propose the following changes to the C++ Standard,
> the goal of which are to provide an improved ability to specify
> the constraints on type parameters to templates.
..

A flaw in what I've proposed is that it there are likely to be
practical situations when there are constraints on how multiple
type parameters that cannot be expressed as contraints on
an individual type parameter.  The solution that occurs to
me is add the rule that, if a type parameter to the template
being declared has the same name as a type parameter to
a template used as a constraint, the actual parameter for
both must be the same.  A simple example:

template <typename P>
class Child
  {
  public:
    // Get/set parent.
    void parent(P *p);
    P *parent(void) const;
  };

template <typename C>
class Parent
  {
  public:
    // Return children.
    vector<C *> children(void) const;
  };

template <
  class Parent ~ template<class Child> Parent,
  class Child ~ template<class Parent> Child >
class Do_stuff_with_trees
  {
  ...
  };


Unrelated thought:  multiple constraints may be desirable:
template <typename Whip ~ class Floor_wax ~ class Dessert_topping>
..


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

wkaras@yahoo.com wrote:
> I would like to propose the following changes to the C++ Standard,
> the goal of which are to provide an improved ability to specify
> the constraints on type parameters to templates.  Let me say  from
> the start that my knowledge of compiler implementation is very
> limited.  Therefore, my suggestions may have to be rejected
> because they are difficult or impossible to implement.

What you propose may be addressed by existing proposals to introduce
"Concepts" into C++. There are two active proposals in this area:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1758.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1782.pdf

  Doug


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]