std.container & ranges

[Paolo Invernizzi]

On Nov 2, 2011, at 12:48 PM, Steven Schveighoffer wrote:

>> Hello again.
>> 
>> I've read all further replies in this thread, but it seems to me this is the most appropriate place to respond.
>> 
>> Simply put, all of those options are too verbose. If what you want to do is simple, the syntax should also be simple, this is what I love about D. As a side-note, I don't come from Java, but I still expect a container to be able to remove an element by passing it to a method. The verbosity and the details of this operation should be hidden in the implementation of the method and I shouldn't need to know about the details. Otherwise, I could just as well implement my own container.
> 
> The basic response to this is, when dealing with containers generically (that is, you know you have a container, but you don't know what type), the "remove this element" operation is not necessarily a good primitive to have.
> 
> Simply because from the myriad of containers, only some can implement this operation efficiently.  Java embeds this operation in the interface, which means any interface you have to a container could potentially use O(n) time to remove that element.  Such an innocuous piece of syntax *should* have a cost if it's not efficient IMO.
> 
> BTW, the original question doesn't provide enough information to say "remove this element."  Even in Java, if you aren't using the default comparison, you must use a comparator method to determine which one to remove.  If cell.x == x && cell.y == y *is* the comparison operator for the type, then the syntax gets much simpler, because you don't need to pass a specialized comparison function.
> 
> In dcollections, removing a specific element (using the default comparison operator for that element) on a *fast lookup* container is as simple as:
> 
> container.remove(container.find(x));
> 
> Which removes the element x if it's found.  However, this is not defined for containers which use O(n) time to search (such as linked list), you must use std.algorithm.find for that:
> 
> container.remove(find(container[], x).begin);
> 
> Should work, and takes O(n) time.
> 
> -Steve


I can't really understand what is wrong with an inefficient "remove this element" primitive if it's really what the user had to do...
Once it's in the documentation that the operation is inefficient, why the user must be forced to dig into the newsgroup to find out some code? 
Why can't that be furnished in a free function, for example?

Cheers, Paolo