Re: Fwd: Re: [Patch] Remove workaround for copy_backward

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Douglas Gregor <gregod@cs.rpi.edu> writes:

| On Sunday 28 September 2003 11:13 am, you wrote:
| > I was not referring to the fact that our compiler could handle that
| > idiom or not.  I was talking about the set of places that could
| > effectively benefit from that idiom.  That needs auditing.
| 
| I didn't realize which library "the library" was.

I tend to view V3 as a whole, not just an accumulation of components
(even though it is not as coherent as it could be); sorry if that
wasn't clear. 

| It's not an audit, but grep 
| for "dispatch" and "__iterator_category" to get a rough estimate of the 
| places where enable_if could be useful. There are many of them, but most of 
| them fall into a few simple categories (e.g., whether it is integral or not, 
| whether it is a random access iterator or not).

OK.

Here is my take on the template constructror issue.  It is out of
question to add a dummy argument, because:
 (1) it an ABI breaking -- I do not have a strong opinion here;
 (2) it makes us potentially accept "invalid" constructs -- even though
     it may a harmless one.  For some reasons, people tend to use/depend
     on things we think harmless; I'm pretty sure we'll get questions
     like: "why does not vector<> use by nth argument?".
It think the dispatcher does a pretty good job here, even though I
think it should not depend overload resolution.

There are probably other components that can benefit from enable-if,
though. 

| 
| > | Compare it to what libstdc++ currently does. I can tell you that it
| > | doesn't fit in two extra lines of code.
| >
| > Doug, do me a favor:  I understrand the benefit of the enable-if
| > idiom.
| >
| > -- Gaby
| 
| This is a public forum. You know the benefit of enable_if and I know the 
| benefit of enable_if, but can we both be sure that everyone here knows it? 

enable_if has been explained when it was introduced in the library :-)