Bug 6547 – Call to std.algorithm.remove causes compile error
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
phobos
Product
D
Version
D2
Platform
All
OS
All
Creation time
2011-08-23T20:52:00Z
Last change time
2012-06-08T02:05:32Z
Assigned to
nobody
Creator
itsallaboutthedyo
Comments
Comment #0 by itsallaboutthedyo — 2011-08-23T20:52:31Z
This minimal use case generates an error in std.algorithm:
char[] s = "<html>Some fake HTML for your testing pleasure</html>".dup;
auto start = s.find("<");
auto len = s[start..$].find(">");
s = s.remove(tuple(start, start+len+1));
writeln(s);
The compile error I get from this is:
/usr/local/Cellar/dmd/2.054/src/phobos/std/algorithm.d(5826): Error: front(src) is not an lvalue
/usr/local/Cellar/dmd/2.054/src/phobos/std/algorithm.d(5826): Error: front(tgt) is not an lvalue
I pulled the most current version of Phobos from github and it has the same problem, though there it occurs on line 5933.
Comment #1 by yuri.gorobets — 2012-02-16T03:25:32Z
(In reply to comment #0)
This behavior appears to be as designed. The compilation problem is caused by special treatment of the "narrow strings" by std.array:
http://dlang.org/glossary.html#narrow%20strings
import std.array;
import std.algorithm;
void main()
{
char[] s = "narrow".dup;
s.remove(0); // Error: template std.algorithm.move(T)
// does not match any function template declaration
// Error: template std.algorithm.move(T) cannot deduce
// template function from argument types !()(dchar,dchar)
// remove troubles are caused by the special treatment of narrow strings
// front(s) doesn't return a char reference but dchar value instead:
s.front = 'c'; // Error: s.front is not an lvalue
}
dchar version works fine:
void main()
{
dchar[] u = "unicode"d.dup;
u.remove(0); // works fine
u.front = 'c';
}
Comment #2 by itsallaboutthedyo — 2012-03-13T15:39:44Z
I will say that I don't agree with this assessment -- the bug isn't really about user error while operating on a narrow string, but about how the compiler & library combo respond to that misuse. To wit, anytime a user gets a cryptic error message buried deep inside a library in response to a simple mistake, you have disempowered them from solving their own problem and derailed their momentum in learning the language.
That said, under 2.058 the error message is now:
test.d(11): Error: cannot implicitly convert expression (start) of type char[] to ulong
Which makes it clear that find(string, string) is returning a slice. I think this specific issue should be closed.
Comment #3 by itsallaboutthedyo — 2012-03-16T12:26:44Z
The minimal use case described by Yuri above still occurs with 2.058.
If this isn't supposed to work for narrow strings, then perhaps a template specialization for the unsupported types that raises a useful error message is the right solution here?
Comment #4 by lovelydear — 2012-04-22T03:24:38Z
Reduced to "normal"
Comment #5 by issues.dlang — 2012-06-08T02:05:32Z
As of 2.059, this is the error that you get:
q.d(10): Error: cannot implicitly convert expression (start) of type char[] to ulong
q.d(11): Error: template std.typecons.tuple does not match any function template declaration
/home/jmdavis/dmd2/linux/bin/../../src/phobos/std/typecons.d(687): Error: template std.typecons.tuple(T...) cannot deduce template function from argument types !()(char[],_error_)
which is much better than the one originally reported.