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