std.range.interfaces : InputRange moveFront

Steven Schveighoffer schveiguy at yahoo.com
Fri Dec 1 15:21:44 UTC 2017


On 12/1/17 4:29 AM, Johan Engelen wrote:
> On Friday, 1 December 2017 at 09:11:40 UTC, Johan Engelen wrote:
>>
>> I tested it and it works like you wrote, but the behavior is different 
>> for an array of integers...:
> 
> Hmm, I guess I misread what Ali meant. But the documentation is 
> wrong/very confusing for moveFront:
> It says "moveFront -- Removes the front element of a range." and "Moves 
> the front of r out and returns it."  With "to move _out_", I would 
> expect that the range is advanced/shortened/..., but it is not.

move is supposed to move the bits from one place to another (i.e. 
without calling any constructor or postblit). It doesn't destroy the 
existence of the original, it's supposed to leave it as an empty shell 
(read: set the original to it's .init value).

However, I'm surprised the front element is still 1. I would think it 
should be int.init. But I guess it makes sense that if a type doesn't 
have a destructor, there's no need to worry about initializing it. move 
probably doesn't care if it's a value type without a destructor.

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

> So which function name is given to the behavior of "pop" of other 
> languages?)

Nothing. You have to do both front and popFront. Others have proposed a 
wrapper that does both, but in order to truly take advantage of the fact 
that you are removing and calculating the front value at the same time, 
you need a new range type. Some have suggested that too.

-Steve


More information about the Digitalmars-d-learn mailing list