std.range.interfaces : InputRange moveFront

[Steven Schveighoffer]

On 12/3/17 12:42 AM, Johan Engelen wrote:
> On Friday, 1 December 2017 at 18:33:09 UTC, Ali Çehreli wrote:
>> On 12/01/2017 07:21 AM, Steven Schveighoffer wrote:
>> > On 12/1/17 4:29 AM, Johan Engelen wrote:
>>
>> >> (Also, I would expect "popFront" to return the element
>> popped, but it
>> >> doesn't, OK...
>> >
>> > pop removes the front element, but if getting the front
>> element is
>> > expensive (say if it's a map with a complex lambda function),
>> you don't
>> > want to execute that just so you can return it to someone who
>> doesn't
>> > care. This is why front and popFront are separate.
>>
>> Yet, we're told that compilers are pretty good at eliminating that 
>> unused copy especially for function templates where all code is visible.
> 
> I assume that Steven means "copying the front element" when he wrote 
> "getting the front element"?

No I mean generating the front element. For example:

auto m = [1, 2, 3].map!(a => reallyExpensiveFunction(a));

Each time you call front, it's going to be really expensive. If you 
aren't going to use it, then generating it is wasted cycles.

(BTW, I said "pop" when I meant "popFront", sorry for *that* confusion too!)

> There is no need for a copy, because the 
> element will be removed from the range, so we can move (whose cost only 
> depends on the size of the element, internal pointers being disallowed 
> by the language).

Yeah, this wasn't my concern, sorry for being ambiguous.

-Steve