Bug 12086 – std.algorithm.remove + range of indices produces wrong results
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
phobos
Product
D
Version
D2
Platform
All
OS
All
Creation time
2014-02-05T12:52:34Z
Last change time
2018-06-13T16:02:55Z
Keywords
pull
Assigned to
No Owner
Creator
Justin Whear
Comments
Comment #0 by justin — 2014-02-05T12:52:34Z
While the documentation for std.algorithm.remove does not mention using a range of indices, it quietly accepts such. Given that std.algorithm deals extensively in ranges, there is an implicit expectation that a range of indices should work--an expectation that is confirmed by the fact that such a usage of remove both compiles and runs.
---------------------------------------
import std.stdio, std.algorithm;
void main(string[] args)
{
writeln( [0,1,2,3,4].remove(1, 3) );
// 0, 2, 4 -- correct
writeln( [0,1,2,3,4].remove([1, 3]) );
// 0, 3, 4 -- incorrect
}
---------------------------------------
Comment #1 by safety0ff.bugz — 2014-06-11T14:31:10Z
I think this is a combination of a documentation bug and a remove bug:
The documentation bug is that it should accept any range of indices with length 1 or 2.
Currently it is only documented that tuples of length 2 should be accepted, but I don't see why tuples should be special.
Secondly:
import std.stdio, std.algorithm;
void main(string[] args)
{
writeln( [0,1,2,3,4].remove(1, 3) );
// 0, 2, 4 -- correct
writeln( [0,1,2,3,4].remove([1, 3]) );
// 0, 3, 4 -- correct
writeln( [0,1,2,3,4].remove(tuple(1,3)) );
// 0, 3, 4 -- correct
writeln( [0,1,2,3,4].remove([1,3,4]) ); // should error on invalid args
// 0, 3, 4 -- incorrect
writeln( [0,1,2,3,4].remove(tuple(1,3,4)) ); // should error on invalid args
// 0, 3, 4 -- incorrect
}
Comment #2 by safety0ff.bugz — 2014-06-13T15:44:44Z
(In reply to safety0ff.bugz from comment #1)
> I think this is a combination of a documentation bug and a remove bug:
> The documentation bug is that it should accept any range of indices with
> length 1 or 2.
> Currently it is only documented that tuples of length 2 should be accepted,
> but I don't see why tuples should be special.
Reflecting about this I realised that it is error prone, so tuples should be the only way to specify a range of indices.
I think to fix this a relatively short deprecation cycle should be introduced to avoid breaking code.