Should this work?

[Regan Heath]

On Thu, 09 Jan 2014 14:07:36 -0000, Manu <turkeyman at gmail.com> 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/