Should this work?

[John Colvin]

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;
}