std.container & ranges
Steven Schveighoffer
schveiguy at yahoo.com
Thu Nov 3 08:12:12 PDT 2011
On Thu, 03 Nov 2011 03:41:27 -0400, Mike Parker <aldacron at 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
More information about the Digitalmars-d-learn
mailing list