questions: remove from SList

[Steven Schveighoffer]

On Tue, 11 Oct 2011 05:19:41 -0400, enuhtac <enuhtac_lists at gmx.de> wrote:

> Hello,
>
> I have two issues removing items from a SList.
> Consider following code:
>
>
> import std.container;
> import std.algorithm;
>
> void main()
> {
>     SList!int a = [ 5, 4, 3, 2, 1 ];
>     auto r = a[];
>     remove( r, 2 ); // ERROR! Needed member function are not
>                     // implemented by SList(T).Range
>     a.remove( r );  // ERROR! There is no member function remove
> }
>
>
> * The call to algorithm.remove produces these error messages:
>
> /usr/include/d/dmd/phobos/std/algorithm.d(5951): Error: src.front() is
> not an lvalue
> /usr/include/d/dmd/phobos/std/algorithm.d(5951): Error: tgt.front() is
> not an lvalue
> /usr/include/d/dmd/phobos/std/algorithm.d(5954): Error: no property
> 'popFrontN' for type 'Range'
> /usr/include/d/dmd/phobos/std/algorithm.d(5956): Error: no property
> 'popBack' for type 'Range'
>
> I would presume that phobos algorithms should work for all phobos
> containers, right? - At least if the prerequisites are met. The relevant
> prerequisite for this version of "remove" is "isForwardRange!Range"
> which is clearly the case for SList(T).Range. Nevertheless "remove"
> tries to access "popFrontN" and "popBack" which are not part of the
> ForwardRange specification. The lvalue-errors are another issue.
> I would clearly say this implementation of remove is buggy - or am I  
> wrong?

Yes, I'd agree either remove's implementation or its constraint  
specification are buggy.  It should not specify that it needs a forward  
range and then use bi-directional range primitives.

However, I don't think std.algorithm.remove does what you want, I think it  
moves data that is not desired to the end of the range (not exactly sure).

> * The second call to remove does not succeed because there is no member
> function "remove". Instead there is "linearRemove". This is not a bug of
> course. But if I want to write code that uses some unspecific container
> it is very inconvenient that instead of "remove" I might have to call
> "linearRemove" or "stableRemove". Why not add a simple
>
> alias linearRemove remove ?

The exact point of why SList contains linearRemove and not remove is so  
that code which expects sub-linear remove function will not compile for  
SList, because SList does not support quick removal.  Aliasing remove to  
linearRemove would defeat the purpose of using function names to imply  
complexity and side-effects, which is one of the main charters of  
std.container.

There's always dcollections ;)

http://www.dsource.org/projects/dcollections

-Steve