Should this work?

Manu turkeyman at gmail.com
Fri Jan 10 08:14:41 PST 2014


On 10 January 2014 00:07, 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.
>

One more, again here to reduce spam...

2 overloads exist:
void func(const(char)* str);
void func(const(char)[] str);

Called with literal string:
func("literal");

called with argument types (string) matches both.

I appreciate the convenience of the automatic string literal ->
const(char)* cast. But in this case, surely it should just choose the array
version of the function, like it does it calling with a 'string' variable?
The convenience should be just that, a convenience, not a hard rule...?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140111/ea8a2450/attachment-0001.html>


More information about the Digitalmars-d mailing list