Boost logo

Boost :

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-02-18 15:48:12

----- Original Message -----
From: "Douglas Gregor" <gregod_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, February 18, 2002 5:06 PM
Subject: Re: [boost] Most needed/desired features in C++

> On Monday 18 February 2002 02:09 pm, you wrote:
> [snip]
> > Tagging types can be totally done with traits classes.
> > The key of this proposal is that tags defined this way participate in
> > overload resolution, much like base classes does, except that unlike
> > classes they are used to sort out types in the last phase instead of the
> > first.
> > Their main purpose is to resolve ambiguities and to group
> >
> > template<class GPoint T> double distance ( T const& lhs, T const& rhs )
> > // won't clash with std::distance
> As I see it, tags provide a way to control when a template type parameter
> be bound to a particular type. This, I believe, is an extremely important
> ability and in some form it should be supported in C++0x. However, if tags
> are semantically equivalent to traits, why the new name and syntax?
> If I were to counter-propose something along these lines, I would propose
> that template parameters can optionally be followed by a restriction of
> form:
> IF '(' expression ')'
> template parameters may only be bound to types such that 'expression'
> evaluates true. Just to compare on your example, the following declaration
> using tags:
> template<class GPoint T> double distance ( T const& lhs, T const& rhs ) ;
> would be written:
> template<class T if (is_gpoint<T>::value)>
> double distance ( T const& lhs, T const& rhs ) ;
> I personally would prefer that the extension be formulated in this way
> because:
> 1) it's a pure extension, that will not break any existing code
> 2) it builds on existing knowledge and implementations of traits
> 3) it allows arbitrary expressions to determine binding (perhaps tags
> do this also?)
> 4) it's utterly trivial to implement
> Doug
We agree on main the functionality we're looking for.
As you properly recognized, the key functionality is in the restriction made
when bounding template parameters to a concrete type.
AFAICT, your syntax does allow most of the behavior I wanted.

I agree with argument 2.
I'm not sure if tags as I outlined them would break existing code, so reason
1 may not apply.

Consider a "tag expression" to be the expression that is used to rule out a
given candidate type during matching.
In my proposal, a tag expression was simply a tagname, where the equality
test was implicitly used, but tagnames could be made to participate in
complex expressions too, so (3) is not a reason to prefer traits instead of
true tags.

In order for this to be really useful, 'tag expressions' should be allowed
to be used for specializations too.
Following your syntax, this would look something like:

template<class T> struct Some {} ;

template<class T> struct Some< is_output_iterator_tag<T>::value > {} ;

But this doesn't fit properly into current C++. Something else would be
needed here.

Based on the last situation, I have the intuition that tagnames should not
be typenames, as they currently are (but I have to find out why I feel that
way precisely!).

As for 4, tagnames would require a bit of extra work for the compilers, but
probably not that much compared to allowing tag expressions (either way they
are specifically supported).

Fernando Cacciola
Sierra s.r.l.

Boost list run by bdawes at, gregod at, cpdaniel at, john at