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
> > prohibit the overload from having additional functionality (e.g.
> > with different types). But in any case the language you quote isn't
> > 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
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
Yeah, that was a typo. I hope I made it clear what I meant in another
> 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, 184.108.40.206/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,
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk