On Friday, 10 January 2014 at 14:02:21 UTC, Manu wrote:
On 10 January 2014 00:07, 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 won't start another annoying thread.
What's the go with popFront()... it returns nothing?
I almost always want to pop and return the front element. I
can't find a
function to do that... have I missed something again?
Popping the front off a range doesn't necessarily require the
work needed to return the front itself. A trivial example would
be a range of e^n : popFront just incrememnts n but calculating
front requires the relatively expensive exponentiation.
Also, it is legal call popFront on a range with only one element
remaining, leaving it empty. It is not valid to then look at the
front.
You want both at once? take a look at the various std.range.take*
