Should this work?

[Manu]

On 10 January 2014 06:34, Jacob Carlborg <doob at 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 :/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140110/d4031c07/attachment-0001.html>