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