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.

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

On Thursday, 9 January 2014 at 14:08:02 UTC, Manu wrote:
>
> Is that wrong? That seems to be how the docs suggest it should be used.
>

--
string s = find(retro("Hello"), "H").source;
--
Is that working?

Am 09.01.2014 15:07, schrieb Manu:
>
> 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.  C# has way more utility functions that are named in a way that actually helps you understand what they do.

The best example in D is the deprection of indexOf. Now you have to call countUntil. But if I have to choose between the two names, indexOf actually tells me what it does, while countUntil does not. count until what? The confusion mostly comes from the condition which is a template argument with default value. Not to speak of the issues with UTF8 characters, where countUntil does not actually give you a index into the array, but actually gives you the index of the character it found. So you can't use whatever comes out of countUntil for slicing.


-- 
Kind Regards
Benjamin Thaut

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

In order to return the result as a string it would require an allocation. You have to request that allocation (and associated eager evaluation) explicitly

string y = "Hello".retro.find('H').to!string;


However, I think to get the expected result from unicode you need

string y = "Hello".byGrapheme.retro.find('H').to!string;

but I might be wrong.

On 10 January 2014 00:19, Tobias Pankrath <tobias@pankrath.net> wrote:

> On Thursday, 9 January 2014 at 14:08:02 UTC, Manu wrote:
>
>>
>> Is that wrong? That seems to be how the docs suggest it should be used.
>>
>>
> --
> string s = find(retro("Hello"), "H").source;
> --
> Is that working?
>

If I have to type that, I'm going to write my own string library... There's no argument where that can be considered superior to: strrchr("Hello", 'H');

Am Fri, 10 Jan 2014 00:33:28 +1000
schrieb Manu <turkeyman@gmail.com>:

> On 10 January 2014 00:19, Tobias Pankrath <tobias@pankrath.net> wrote:
> 
> > On Thursday, 9 January 2014 at 14:08:02 UTC, Manu wrote:
> >
> >>
> >> Is that wrong? That seems to be how the docs suggest it should be used.
> >>
> >>
> > --
> > string s = find(retro("Hello"), "H").source;
> > --
> > Is that working?
> >
> 
> If I have to type that, I'm going to write my own string library... There's no argument where that can be considered superior to: strrchr("Hello", 'H');

If you do let me know, we can merge the efforts.
Coincidentally what I started uses your std.simd:
http://code.dlang.org/packages/fast
https://github.com/mleise/fast

I haven't pushed the latest changes which include updates to the latest D versions and switching between lookup tables and SSE3 for char in string search.

The idea is to build a collection of the fastest versions of basic utility functions. No safety nets, no garbage collection.

-- 
Marco

On 10 January 2014 00:34, John Colvin <john.loughran.colvin@gmail.com>wrote:

> 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
>>
>
> In order to return the result as a string it would require an allocation. You have to request that allocation (and associated eager evaluation) explicitly
>
> string y = "Hello".retro.find('H').to!string;
>

Ah yes. Well I really just want the offset anyway...


However, I think to get the expected result from unicode you need
>
> string y = "Hello".byGrapheme.retro.find('H').to!string;
>
> but I might be wrong.
>

Bugger that. This is not an example of "D is good at strings!".

On Thursday, 9 January 2014 at 14:34:43 UTC, John Colvin wrote:
> 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
>
> In order to return the result as a string it would require an allocation. You have to request that allocation (and associated eager evaluation) explicitly
>
> string y = "Hello".retro.find('H').to!string;
>
>
> However, I think to get the expected result from unicode you need
>
> string y = "Hello".byGrapheme.retro.find('H').to!string;
>
> but I might be wrong.

Oh. I see you actually wanted strrchr behaviour. That's different.

On 10 January 2014 01:04, Marco Leise <Marco.Leise@gmx.de> wrote:

> Am Fri, 10 Jan 2014 00:33:28 +1000
> schrieb Manu <turkeyman@gmail.com>:
>
> > On 10 January 2014 00:19, Tobias Pankrath <tobias@pankrath.net> wrote:
> >
> > > On Thursday, 9 January 2014 at 14:08:02 UTC, Manu wrote:
> > >
> > >>
> > >> Is that wrong? That seems to be how the docs suggest it should be
> used.
> > >>
> > >>
> > > --
> > > string s = find(retro("Hello"), "H").source;
> > > --
> > > Is that working?
> > >
> >
> > If I have to type that, I'm going to write my own string library... There's no argument where that can be considered superior to: strrchr("Hello", 'H');
>
> If you do let me know, we can merge the efforts. Coincidentally what I started uses your std.simd: http://code.dlang.org/packages/fast https://github.com/mleise/fast
>
> I haven't pushed the latest changes which include updates to the latest D versions and switching between lookup tables and SSE3 for char in string search.
>
> The idea is to build a collection of the fastest versions of basic utility functions. No safety nets, no garbage collection.
>

Awesome! Although it looks like you still have a lot of work ahead of you :)