Should this work?
Tobias Pankrath
tobias at pankrath.net
Thu Jan 9 06:17:09 PST 2014
On Thursday, 9 January 2014 at 14:08:02 UTC, Manu 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.
std.algorithm.find returns the type it gets as input, so it's
retros return type and not string. I agree, that it isn't always
obvious which types are expected or returned in std.algorithm and
especially std.container
More information about the Digitalmars-d
mailing list