C++03までのSTLには、std::xxx_if(..., Pred pred)に対応するalgorithm std::xxx(..., T t)が存在して、それはstd::xxx_if(..., std::bind2nd(std::equal_to<T>(), t))と同じことを行うようになっています。
この名前付け規則に従うと、もしstd::copy_if(first, last, result, pred)があるならば、範囲[first, last)についてtと等しいもののみをresult以降にコピーするalgorithm std::copy(first, last, result, t)が必要になってしまいます。こんなalgorithmはナンセンスですし、そもそもstd::copyはすでに普通のコピーをするalgorithmとして存在します。さらに、std::copy_if(first, last, result, pred)はstd::remove_copy_if(first, last, result, std::not1(pred))で実現できるので、わざわざ理屈を曲げてまでstd::copy_ifを導入する必要はないと判断されたのでしょう。多分。
copy_if (スコア:3, 興味深い)
Re:copy_if (スコア:2, 参考になる)
一応補足を。
C++03までのSTLには、std::xxx_if(..., Pred pred)に対応するalgorithm std::xxx(..., T t)が存在して、それはstd::xxx_if(..., std::bind2nd(std::equal_to<T>(), t))と同じことを行うようになっています。
この名前付け規則に従うと、もしstd::copy_if(first, last, result, pred)があるならば、範囲[first, last)についてtと等しいもののみをresult以降にコピーするalgorithm std::copy(first, last, result, t)が必要になってしまいます。こんなalgorithmはナンセンスですし、そもそもstd::copyはすでに普通のコピーをするalgorithmとして存在します。さらに、std::copy_if(first, last, result, pred)はstd::remove_copy_if(first, last, result, std::not1(pred))で実現できるので、わざわざ理屈を曲げてまでstd::copy_ifを導入する必要はないと判断されたのでしょう。多分。
ただ、そういった理屈はともかく、remove_copy_ifを使った方法では二重否定になってしまい、わかり辛いことは確かで。まあstd::copy_ifが導入されたというのは正しい判断だと思います。
ちなみに、近い将来boost library [boost.org]にrange_ex [sourceforge.net]が受理されれば_if版algorithmというのは必要なくなり、std::copy(range | boost::adaptors::filtered(pred), result)という風に書けるようになります。
Re:copy_if (スコア:1, すばらしい洞察)
その辺の事情は途中までは理解できるんですが、「だから、入れない」はやっぱり仕様のバグだったと思っています。命名規則に合わないのが問題だったら、名前を変えて入れれば良かったのです。choose でも pick でも remove_copy_unless でも、適切な名前はいくらでもあるでしょ。
もう、草案にcopy_ifが入ったんだから、文句をいっても実益はないけど。というか、これまで文句を言った人がたくさんいたから、今回の草案に入ったのでしょうね。