On 1/10/14 7:23 AM, Manu wrote:
> 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.

I doubt it simplifies a lot.

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

If it would have been frequent, it would have been a common request. Apparently it isn't. Even before ranges there wasn't a function that got you s[0] and also assigned s = s[1 .. $] in one shot, and that wasn't asked for either.


Andrei

I expected popFront at first to return the popped element as well, and would use a function like that. You're not alone. But... like you did, I'd just define my own convenience function and UFCS keeps everything readable so no biggie. But something in Phobos would be better, methinks. std.range.take is similar, but not the same since it returns a range and not an element. Also, it requires passing in the very common "1" as an argument.

Atila

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

On Friday, 10 January 2014 at 19:57:56 UTC, Andrei Alexandrescu wrote:
> On 1/10/14 7:23 AM, Manu wrote:
>> 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.
>
> I doubt it simplifies a lot.

A lot, no. Enough to justify its existence, yes. IMHO anyway.

>
>> 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.
>
> If it would have been frequent, it would have been a common request. Apparently it isn't. Even before ranges there wasn't a function that got you s[0] and also assigned s = s[1 .. $] in one shot, and that wasn't asked for either.

I think anybody who wanted it, like me, just wrote their own utility function and moved on.

Atila

On Friday, 10 January 2014 at 20:08:32 UTC, Atila Neves wrote:
> I expected popFront at first to return the popped element as well, and would use a function like that. You're not alone. But... like you did, I'd just define my own convenience function and UFCS keeps everything readable so no biggie. But something in Phobos would be better, methinks. std.range.take is similar, but not the same since it returns a range and not an element. Also, it requires passing in the very common "1" as an argument.

It's not ideal as full-speed performance depends on the Take struct being optimised away, but there is always:

auto blah  = range.takeOne.front;

On Friday, 10 January 2014 at 20:23:32 UTC, John Colvin wrote:
> On Friday, 10 January 2014 at 20:08:32 UTC, Atila Neves wrote:
>> I expected popFront at first to return the popped element as well, and would use a function like that. You're not alone. But... like you did, I'd just define my own convenience function and UFCS keeps everything readable so no biggie. But something in Phobos would be better, methinks. std.range.take is similar, but not the same since it returns a range and not an element. Also, it requires passing in the very common "1" as an argument.
>
> It's not ideal as full-speed performance depends on the Take struct being optimised away, but there is always:
>
> auto blah  = range.takeOne.front;

What's that the point of writing that over:
auto blah  = range.front;
?

On Friday, 10 January 2014 at 19:40:35 UTC, Manu wrote:
> On 11 January 2014 00:31, John Colvin
>> On Friday, 10 January 2014 at 14:28:09 UTC, John Colvin wrote:
>> 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.

Could you confirm that what you wanted is:
"pop, then take the new front" [1]
and not
"pop and get the popped element" [2]
?

In case of [1], how do you know if you can call the function, as knowing not empty is not enough? Take a range with a single element: First you pop, then it's empty, then you take front (boom).

In case of [2], honestly, I've never felt the need for that. As I said previously, I think it's better to pop *once* you are done with the object, rather than once you start using it. It's better in terms of exception safety, and in certain cases, a premature pop can invalidate the element you want to operate on (byLine) :/

On Friday, 10 January 2014 at 20:33:29 UTC, monarch_dodra wrote:
> On Friday, 10 January 2014 at 20:23:32 UTC, John Colvin wrote:
>> On Friday, 10 January 2014 at 20:08:32 UTC, Atila Neves wrote:
>>> I expected popFront at first to return the popped element as well, and would use a function like that. You're not alone. But... like you did, I'd just define my own convenience function and UFCS keeps everything readable so no biggie. But something in Phobos would be better, methinks. std.range.take is similar, but not the same since it returns a range and not an element. Also, it requires passing in the very common "1" as an argument.
>>
>> It's not ideal as full-speed performance depends on the Take struct being optimised away, but there is always:
>>
>> auto blah  = range.takeOne.front;
>
> What's that the point of writing that over:
> auto blah  = range.front;
> ?

oh... I thought the take functions advanced the range.

On Friday, 10 January 2014 at 20:43:31 UTC, John Colvin wrote:
> On Friday, 10 January 2014 at 20:33:29 UTC, monarch_dodra wrote:
>> On Friday, 10 January 2014 at 20:23:32 UTC, John Colvin wrote:
>>> It's not ideal as full-speed performance depends on the Take struct being optimised away, but there is always:
>>>
>>> auto blah  = range.takeOne.front;
>>
>> What's that the point of writing that over:
>> auto blah  = range.front;
>> ?
>
> oh... I thought the take functions advanced the range.

Well, first, you'd have to actually *pop* said take range. Here, you are just building one, and taking its front, but not popping it. Second, the range would have to be an actual reference  type, or you'd just be popping a copy of the original range. And still, that's if its not outright sliced.

The inclusion of "takeOne" here seems not only useless, but potentially counterproductive to what we are trying to achieve.

On Friday, 10 January 2014 at 20:56:23 UTC, monarch_dodra wrote:
> On Friday, 10 January 2014 at 20:43:31 UTC, John Colvin wrote:
>> On Friday, 10 January 2014 at 20:33:29 UTC, monarch_dodra wrote:
>>> On Friday, 10 January 2014 at 20:23:32 UTC, John Colvin wrote:
>>>> It's not ideal as full-speed performance depends on the Take struct being optimised away, but there is always:
>>>>
>>>> auto blah  = range.takeOne.front;
>>>
>>> What's that the point of writing that over:
>>> auto blah  = range.front;
>>> ?
>>
>> oh... I thought the take functions advanced the range.
>
> Well, first, you'd have to actually *pop* said take range. Here, you are just building one, and taking its front, but not popping it. Second, the range would have to be an actual reference  type, or you'd just be popping a copy of the original range. And still, that's if its not outright sliced.
>
> The inclusion of "takeOne" here seems not only useless, but potentially counterproductive to what we are trying to achieve.

I agree, my mistake.

On 11 January 2014 01:20, John Colvin <john.loughran.colvin@gmail.com>wrote:

> On Friday, 10 January 2014 at 15:19:39 UTC, John Colvin wrote:
>
>> On Friday, 10 January 2014 at 15:05:18 UTC, monarch_dodra wrote:
>>
>>> On Friday, 10 January 2014 at 14:31:31 UTC, John Colvin wrote:
>>>
>>>> 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;
>>>> }
>>>>
>>>
>>> *Unless* I'm mistaken, he was asking for something that returns the *popped* element?
>>>
>>> Re-reading the question, it does kind of sound a bit ambiguous now.
>>>
>>
>> Woops, of course:
>>
>> auto popFrontRet(R)(ref R range)
>>     if(isInputRange!R)
>> {
>>     auto tmp = range.front;
>>     range.popFront();
>> }
>>
>>
>> That also invalidates my second point to do with emptiness.
>>
>
> ugh, today is not my day:
>
>  auto popFrontRet(R)(ref R range)
>>     if(isInputRange!R)
>> {
>>     auto tmp = range.front;
>>     range.popFront();
>>     return tmp;
>> }
>>
>
Yes, this is what I did. It should be added to phobos, but I figured
there's a reason it's not there...
My point was, I want this more often than I want either of those other
primitives. I'm surprised it doesn't exist, and suspected I was just being
blind again.

I also wrote popFrontRetN to capture more than one element from the start.