On Thu, 09 Jan 2014 14:07:36 -0000, Manu <[email protected]> wrote:
This works fine:
string x = find("Hello", 'H');
This doesn't:
string y = find(retro("Hello"), 'H');
> Error: cannot implicitly convert expression (find(retro("Hello"),
'H'))
of type Result!() to string
Is that wrong? That seems to be how the docs suggest it should be used.
On a side note, am I the only one that finds std.algorithm/std.range/etc
for string processing really obtuse?
I can rarely understand the error messages, so say it's better than STL
is optimistic.
Using std.algorithm and std.range to do string manipulation feels really
lame to me.
I hate looking through the docs of 3-4 modules to understand the complete
set of useful string operations (std.string, std.uni, std.algorithm,
std.range... at least).
I also find the names of the generic algorithms are often unrelated to
the name of the string operation.
My feeling is, everyone is always on about how cool D is at string, but
other than 'char[]', and the builtin slice operator, I feel really
unproductive whenever I do any heavy string manipulation in D.
I also hate that I need to import at least 4-5 modules to do anything
useful with strings... I feel my program bloating and cringe with every
gigantic import that sources exactly one symbol.
I feel exactly the same way. I must admit I haven't done any serious D
for a couple of years now, and the main reason is lack of free time, but
the other is that each time I come back to try and do something I get
weird arse error messages like the one you got above.
I realise that it is probably the way it is, to avoid bloating the
language with several ways to do the same thing. I agree with that
position, however.. I don't think it's a bad thing (TM) to have a
custom/specific set of operations for a given area which re-use more
generic operations behind the scenes.
In other words, why can't we alias or wrap the generic routines in
std.string such that the expected operations are easy to find and do
exactly what you'd expect, for strings.
If someone is dealing with generic code where the ranges involved might be
strings/arrays or might be something else of course they will call
std.range functions, but if they are only dealing with strings there
should be string specific functions for them to call - which may/may not
use std.range or std.algorithm functions etc behind the scenes.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
