On Tue, 11 Oct 2011 05:19:41 -0400, enuhtac <[email protected]> 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
