On 10 January 2014 06:34, Jacob Carlborg <doob@me.com> wrote:
On 2014-01-09 15:07, 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.

As other as said, the problem is that "find" returns a range, which is not implicitly convertible to "string". The main reason is to avoid temporary allocations when chaining algorithms.

If it was the other way around you would probably be complaining it wasn't efficient enough ;)

Then there's probably a fundamental problem somewhere, and it should be re-thought at a lower level.
Perhaps even something super simple like a can't-go-wrong naming convention, that makes it REALLY plain when string related function are dealing with bytes, codepoints, or graphemes?
It would seem to be that a lot of the confusion and complexity surrounding strings is because it tries to be 'correct' (and varying levels of correct in different circumstances), but there are no clear relationships between different functions that deal with these different versions of 'correct'-ness.


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).

You forgot std.array ;)

I did! And there are probably others too.
You can't do anything without std.typecons either. Although not directly related, it's always seems to be there alongside.

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.

You have built-in appending, concatenation, using strings in switch statements and so on.

Correct, those things are good. That is where 'D is awesome at strings' ends though, in my opinion.

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 agree with you. I have built up a small library through out the years that basically allows me to only import a single module to do most string operations I need.

I suspect your effort is not uncommon. Is this not clear evidence of a critical problem?

You probably don't like it but you could have a look at Tango as well. It contains two useful modules (for this case). One for handling arbitrary array operators and one for string operations.

tango.core.Array
tango.text.Util

https://github.com/SiegeLord/Tango-D2
http://siegelord.github.io/Tango-D2/

Yeah... I want less libraries, not more :/