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.
(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'; }
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.
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?
Reduced to "normal"
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.