Re: [boost] Most needed/desired features in C++

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-02-18 17:04:33

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

> On Monday 18 February 2002 03:48 pm, you wrote:
> > 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.
>
> Okay, we're converging then. I wasn't sure if you had considered the
notion
> of "tag expressions" as well.
>
OK.

> > 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.
>
> I have more questions than answers for this.
We're two then :-)

> In your original message, you
> had the following (I added the #1 and #2):
>
> template<class input_iterator_tag T> struct Some {} ; // #1
>
> template<> struct Some<output_iterator_tag> {} ; // #2
>
> I'm assuming that #1 is used for any type T that has the tag
> 'input_iterator_tag', and #2 is used for any type T that has the tag
> 'output_iterator_tag'? If so, then why isn't #2 written as:
>
> template<class output_iterator_tag T> struct Some {}; // #2?
>
> I ask because #2 looks like a full specialization, but it is actually a
class
> template. Even if tags are in a different namespace from types (as they
would
> have to be), I believe such a construct would cause confusion.
>
Yes, you are right. I wrote those examples off the top of my head, and I
just didn't know exactly how to fit the model with current specialization
semantics, because it is conceptually a sort of "group" partial
specialization, but the current syntax for partial specialization didn't
totally fit.

> For reference, I would write the equivalent to the above as:
>
> template<typename T> struct Some; // undefined
>
> template<typename T if (is_input_iterator_tag<T>::value)>
> struct Some { }; // #1
>
> template<typename T if (is_output_iterator_tag<T>::value)>
> struct Some { }; // #2
>
>
> Multiple primary class templates? Yes, but I think the idea of a 'primary
> template' is misguided anyway once one considers restrictions on the
binding
> of arguments to parameters. Think function overloading: there is no notion
of
> a 'primary function' but there are parameter/argument binding
restrictions.
>
Exactly!!!!
I thougth about this initially, but felt that it was too much of a change,
so I tried out the hybrid syntax I posted.

> In any case, it appears (to me) that the two approaches are roughly
> equivalent in all but syntax.
IIF mutiple primary classes (differing perhaps only in tag expressions) are
allowed.

>On the syntax front, I believe that minimal is
> better: introducing additional keywords and namespaces into the language
will
> complicate it considerably, and is bound to run into a great deal of
> resistance.
>
Absolutely.
If your simpler syntax happens to cover all the funcionality, it is
undoubtly better. And with mutiple primary classes I think it does (I
invented tagnames as different entities just to better fit the current
specialization model, but perhaps it is better to extended it than to invent
more kewords)

P.S: I still think that eventually tags should not be types, but to come out
with true tagging features right from start is very difficult, so an hybrid
approach using traits classes could start to lead the way now.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com