<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 10 January 2014 06:34, Jacob Carlborg <span dir="ltr"><<a href="mailto:doob@me.com" target="_blank">doob@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2014-01-09 15:07, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This works fine:<br>
   string x = find("Hello", 'H');<br>
<br>
This doesn't:<br>
   string y = find(retro("Hello"), 'H');<br>
   > Error: cannot implicitly convert expression (find(retro("Hello"),<br>
'H')) of type Result!() to string<br>
<br>
Is that wrong? That seems to be how the docs suggest it should be used.<br>
</blockquote>
<br></div>
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.<br>
<br>
If it was the other way around you would probably be complaining it wasn't efficient enough ;)<br></blockquote><div><br></div><div>Then there's probably a fundamental problem somewhere, and it should be re-thought at a lower level.</div>
<div>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?</div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On a side note, am I the only one that finds std.algorithm/std.range/etc<br>
for string processing really obtuse?<br>
I can rarely understand the error messages, so say it's better than STL<br>
is optimistic.<br></div><div class="im">
Using std.algorithm and std.range to do string manipulation feels really<br>
lame to me.<br>
I hate looking through the docs of 3-4 modules to understand the<br>
complete set of useful string operations (std.string, std.uni,<br>
std.algorithm, std.range... at least).<br>
</div></blockquote>
<br>
You forgot std.array ;)</blockquote><div><br></div><div>I did! And there are probably others too.</div><div>You can't do anything without std.typecons either. Although not directly related, it's always seems to be there alongside.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I also find the names of the generic algorithms are often unrelated to<br>
the name of the string operation.<br>
My feeling is, everyone is always on about how cool D is at string, but<br>
other than 'char[]', and the builtin slice operator, I feel really<br>
unproductive whenever I do any heavy string manipulation in D.<br>
</blockquote>
<br></div>
You have built-in appending, concatenation, using strings in switch statements and so on.</blockquote><div><br></div><div>Correct, those things are good. That is where 'D is awesome at strings' ends though, in my opinion.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I also hate that I need to import at least 4-5 modules to do anything<br>
useful with strings... I feel my program bloating and cringe with every<br>
gigantic import that sources exactly one symbol.<br>
</blockquote>
<br></div>
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.<br></blockquote><div><br></div><div>I suspect your effort is not uncommon. Is this not clear evidence of a critical problem?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
tango.core.Array<br>
tango.text.Util<br>
<br>
<a href="https://github.com/SiegeLord/Tango-D2" target="_blank">https://github.com/SiegeLord/<u></u>Tango-D2</a><br>
<a href="http://siegelord.github.io/Tango-D2/" target="_blank">http://siegelord.github.io/<u></u>Tango-D2/</a></blockquote><div><br></div><div>Yeah... I want less libraries, not more :/</div></div></div></div>