On Thu, 03 Nov 2011 03:41:27 -0400, Mike Parker <aldac...@gmail.com> wrote:
On 11/2/2011 10:41 PM, Steven Schveighoffer wrote:
Then your specific application can use std.algorithm.find to implement
the equivalent. Only the algorithm body changes, not the usage of the
algorithm.
This is the root of the problem. How are we supposed to know that we
need something from std.algorithm to remove something from a container
in std.container? It's non-intuitive and non-obvious unless you already
have more than a passing familiarity with ranges. If we can't have
remove(element) on a container, then we need some good documentation in
the std.container module that points the way.
The primitive for a container is remove(range). Ranges are essential to
containers, and should be the major interface to them. remove(value)
translates to remove(findRangeFor(value)). I'm asserting that we should
not promote this "shortcut" if it's unavoidably linear in nature,
otherwise, remove(value) has the stigma of being slow, even for containers
which can do it quickly. It's not the only choice, and there are ways to
argue both sides. But the fact that one can still do this using
std.algorithm makes it at least so you can have the best of both worlds --
it's difficult to do, not impossible, but we can still develop generic
code with complexity guarantees.
I agree the documentation needs more care. I think std.container suffers
from neglect in other areas too. I argued this position, however, because
even though it's not spelled out in std.container's docs, it *is* the
position std.container is taking.
-Steve
