Should this work?

[Manu]

On 11 January 2014 00:31, John Colvin <john.loughran.colvin at gmail.com>wrote:

> On Friday, 10 January 2014 at 14:28:09 UTC, John Colvin wrote:
>
>> On Friday, 10 January 2014 at 14:02:21 UTC, Manu wrote:
>>
>>> 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.
>>>>
>>>>
>>> I won't start another annoying thread.
>>>
>>> What's the go with popFront()... it returns nothing?
>>> I almost always want to pop and return the front element. I can't find a
>>> function to do that... have I missed something again?
>>>
>>
>> Popping the front off a range doesn't necessarily require the work needed
>> to return the front itself. A trivial example would be a range of e^n :
>> popFront just incrememnts n but calculating front requires the relatively
>> expensive exponentiation.
>>
>> Also, it is legal call popFront on a range with only one element
>> remaining, leaving it empty. It is not valid to then look at the front.
>>
>> You want both at once? take a look at the various std.range.take*
>>
>
> or if you want something short and simple, define a free function:
> auto popFrontRet(R)(ref R range)
>     if(isInputRange!R)
> {
>     range.popFront();
>     assert(!range.empty);
>     return range.front;
> }
>

This is what I've done. I'm just surprised that such an obvious function
doesn't exist, and suspect I was just retarded at phobos again.
Having a function that does this is kinda important to simplify lots of
expressions that otherwise need to be broken out across a bunch of lines.

Does nobody see this coming up in their code? I have it basically every
time I use ranges, and as usual, surprised others don't feel the same way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140111/4dfffa27/attachment-0001.html>