Re: [boost] Re: Shades, swap or whatever

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-11-01 14:46:59

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>

> > 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?

I think we may be looking at a specific example here which helps prove your
point (one could argue that code which uses std::swap(a, b) should
concept-check a and b to be sure they're the same type), but that a broad
look at the need for specialization/overloading in general may tip the
balance the other way. Just speculating, though.

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

Yeah, that was a typo. I hope I made it clear what I meant in another
message.

> 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.

Not all implementations, anyway. We tried it with CWPro6, for example.

> (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.)

But examples are non-normative. I think this may be a core defect! I wonder
what the core guys will say?

> > 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. :-)

Maybe. But you must appreciate that getting FTPS to work reliably for users
requires not only radical changes in the core language but also in levels of
user education and practice.

-Dave