Re: Shades, swap or whatever

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-11-01 13:27:21

----- Original Message -----
From: "Griffiths, Alan" <Alan.Griffiths_at_[hidden]>

> > -----Original Message-----
> > From: David Abrahams [mailto:abrahams_at_[hidden]]
> >
> > We recognized the problem, then spent a bunch of time trying
> > to figure out
> > why partial specialization might be better than allowing overloading.
>
> Do you need examples?

More examples that illustrate something distinct from the one of Peter's
that I quoted would certainly be helpful.

> > It seems to me that the confusion comes from mixing overloading and
> > specialization. The two mechanisms don't play well together.

That was also my assessment.

> Of course, this is only a problem if both mechanisms are used.
> <grin>And since user-defined overloads are banned in std this could
> still get off the ground.</grin>

Except that people have been exploiting Koenig lookup with overloading. I
firmly believe that is much more common.

> More seriously, this does point towards allowing overloading.
>
> (OTOH there are other benefits available from partial specialization
> of function templates.)

As I said, more examples would be helpful.

> > Since IMO few
> > people have been writing function specializations anyway, and
>
> I know a some - most of them wrote an overload until they realised
> (or were told) the difference.

Right now, you sort of need to do both if you want your bases covered.
Overload in your own namespace and specialize in std. Yuck. But that will
only be solved when we fix this problem and people begin to write generic
code that explicitly selects the std:: algorithms.

> > it's a problem
> > we can solve entirely in the LWG without a change to the core
> > language, it
> > would be better to allow overloading in std and discourage
> > specialization of
> > function templates.
>
> That seems to be a logical conclusion.  (In another world
> we could introduce partial specialization of function templates,
> define the library using it instead of overloading, and
> retain the ban on overloading.)

Not neccessarily productive, though. Generic code in the library would then
follow a very different set of rules than generic code in 3rd party
libraries. I think it might be better to try and focus the language at a
single mechanism.

> Presumably this arises from the interaction with overloading.
> Something like:
>
>     template <class T> void f(T);   // #1
>     template <class T> void f(T*);  // #2
>     template <> void f<int*>(int*); // specialising #1 or #2?

This one's easy. It's a full specialization for #2 (as I wrote in an earlier
message, it is order-dependent).

> Thanks for the update.  (I hope the idea of hijacking names in
> every namespace met a suitable fate.)

Some thought it was patently obvious that it was disallowed (and thus not an
issue in the first place), but I think the general consensus was that such
hijacking is illegal. Whether or not it is considered a defect that we do
not say so is still in question. In particular, the specification for
valarray seems to clearly imply that Koenig lookup /should/ be used in some
cases. So I think there are some fuzzy edges on this one and we're not
exactly sure what the appropriate resolution in the standard is.

-Dave