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
