Re: Shades, swap or whatever

From: Peter Dimov (pdimov_at_[hidden])
Date: 2000-11-01 13:43:48

> > To clarify, you felt that this example is an argument in favour of
> > allowing std:: overloading and not allowing partial specializations?
>
> Not exactly. I felt that it showed that mixing specialization and
> overloading can produce confusing results, at least to someone without
a
> deep understanding of what's going on. Certainly, quite a few
committee
> members were surprised.

Yes; this argument goes both ways, really. It's either specializations
(including partial ones) or overloads.

> > base b;
> > derived d;
> >
> > std::swap(b, d);
> >
> > An overload in this case cannot satisfy 17.4.3.1/1, "meets the
standard
> > library requirements for the original template" - the original
template
> > does not work for different types.
>
> I think you're reading the standard too broadly. The language above
doesn't
> prohibit the overload from having additional functionality (e.g.
working
> with different types). But in any case the language you quote isn't
designed
> for overloading, but for specialization.

"Additional functionality" as in "letting bugs go undetected?" :-) The
language may be interpreted to allow this, granted, but is this what we
want?

> An advantage, to be sure, and not to be understated. A big
disadvantage of
> using function template specialization is that the most obvious syntax
to
> use makes it order-dependent:
>
> template <class T> void f(T);  // #1
> template <> void f<int*>(int*);  // #2
> template <class T> void f(T*);   // #3
>
> #2 specializes #1, but:
>
> template <class T> void f(T);  // #1
> template <class T> void f(T*);   // #3
> template <> void f<int*>(int*);  // #2
>
> Now #2 specializes #3.

No, I don't think so. #2 can never specialize #3. The signature does not
match.

template<> void f<int*>(int**); would specialize #3.

template<> void f(int*); would specialize #3 if you choose to read the
standard in this way, but the existing implementations choose to report
an ambguity in this case, and I think they are correct.

(The issue is whether an explicit specialization with deduced template
parameters that matches more than one primary template uses partial
ordering; 14.7.3/12 says that it does not, 14.5.5.2/1 says that it does.
I'm with 14.7.3/12 on this one, 'cause it has a clear example.)

> Since the specialization for a user-defined type is
> likely to live in a header with the user-defined type declaration,
semantics
> become subject to the vagaries of #include order.

Only if you use the "feature" of not providing the template parameters
explicitly. This should be deprecated. And banned. :-)

--
Peter Dimov
Multi Media Ltd.