From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-03-19 06:33:42
From: "Gary Powell" <powellg_at_[hidden]>
> True enough, but we got here because after using LL for a bit, we started
> wanting more. You know how this goes, first you say, ah hah! We've got
> ll::for_each, then we realize what we want is a nested "count_if" and
pretty
> soon all of the STL algorithms are cloned into lambda. (not the algorithm,
> just a wrapper to forward it to std::STL).
>
> Then we added exceptions, and we realized we needed to be able to
> "construct" objects to throw them. So that got added, then.... and well
you
> can see the result. (or rather the "trim" version.)
I can contribute another point of view on library design in order to balance
things. :-)
When using bind, I sometimes encounter problems that the library doesn't
address directly. Instead of immediately adding the feature, I look at the
problem with the eyes of an "ordinary" user that doesn't have access to the
source, and ask myself: "how can I solve this problem without making changes
to the library?"
For example, how can I make the first argument of a bind() expression be
evaluated? I write a helper apply<> function object. It needs no support
from bind in order to work.
Or, how can I construct an object? I'd provide a construct<T> function
object; again, no changes to bind are necessary, it just works.
How can I throw an exception from within bind? I can write a throw_exception
function object.
Of course, all these helper function objects are not lambda expressions, so
I won't be able to say construct<T>() + _1, but bind(construct<T>()) + _1 is
not _that_ much.
There are things that belong in the library. _1 + _2 is much better than
bind(std::plus<R>(), _1, _2). But we have to draw the line somewhere; you
can't provide direct support in LL for everything; it's better to focus on a
simple, well understood, logical subset of primitives that allow people to
do everything without bothering you with feature requests.