Why is there no combination of popFront and front to pop? (aka Python `next`)

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, February 17, 2016 00:19:09 Seb via Digitalmars-d-learn wrote:
> I am still in the process of learning D - it's a fantastic
> language. Thanks so much!
> However there is one thing that I came by which I think is a bit
> annoying and could be easily solved - there seems to be no way to
> combine `front` and `popFront` in one call even tough this use
> case seems quite frequently to me.
> At least I am used from Python to use next(<some lazy loaded
> stream>) to get its next element and I desperately searched for
> similar method in D.
>
> I know that I can use `.front` and `popFront`, but why isn't
> there `pop` or `next` that returns the first element from the
> lazy loaded range? I know there is `takeOne` (which doesn't
> modify the source) and `dropOne` (which will return the resulting
> array after dropping one element).
>
> In any case such a next method would be very easy to implement
> (see below) and thus I am wondering why it isn't part of phobos?
>
> ```
> auto next(Range)(ref Range a){
>      auto b = a.front;
>      a.popFront();
>      return b;
> }
>
> ````
>
> Thanks for your input!

As far as defining next on a range goes, there are some cases where it would
be more efficient to combine them into one function, but you definitely need
them separate for a lot of use cases, and in previous discussions on it, it
was deemed not worth having an additional function - on that in most cases
is redundant functionality-wise.  Another reason is that having next would
frequently require caching the front value, which isn't  necessarily
desirable, and for some ranges (e.g. the result of byLine), front is reused
such that calling popFront overwrites front, and next fundamentally wouldn't
work in that case (though such ranges often don't play well with many
algorithms anyway - about all they're good for is foreach loops - which is
why byLineCopy was introduced). So, if we were going to have next on a
ranges, we'd need another trait to query for them - e.g. hasNext - and it
would complicate ranges further for marginal benefit.

As for having a free function like you're showing, we could definitely do
that. I expect that the main reason that it's not there is that it does so
little that it probably wouldn't be deemed worth adding, but I don't know.
Also, in my experience, a lot of range-based code doesn't actually put a
popFront right next to a call to front, so it wouldn't help a lot of
range-based code anyway (though I'm sure that it would make some range-based
code simpler).

Feel free to create a pull request to add next. I don't know if it would be
accepted or not. I suspect that it mainly comes down to whether such a
simple function would be deemed worth adding. On some level, it is a
usability improvement, but in theory, we'd prefer to be adding functions to
Phobos which add real value rather than simple wrappers that do basic stuff
that anyone can easily do. So, it may be accepted as a usability
improvement, or it may be rejected on the grounds that it's too simple to be
worth it. You won't know if you don't try though.

- Jonathan M Davis