.array changes the order

[thedeemon via Digitalmars-d-learn]

On Thursday, 12 May 2016 at 10:17:19 UTC, xtreak wrote:

> Thanks a lot. Can you kindly elaborate a little more on 
> File.byLine with an example of the scenario so that I don't get 
> bitten by it. File.byLine.array works as expected for me. A 
> little more explanation on the permutations will also be 
> helpful since joiner.map!array converts the subranges to 
> arrays, so does joiner work by mutating state if so how does it 
> do.

With some ranges the value they return by .front is only valid 
until the next call to popFront(). For example, File.byLine() 
reuses its buffer so after popFront() is called the buffer 
contains different data and if you had references to the contents 
of previously returned value they become invalid. This is why 
byLineCopy() was added. In the same vein permutations() returns a 
range that has a mutable array of indices inside, which changes 
every time popFront() is called, and since every value returned 
by its .front refers to that indices array, if you collect such 
permutations they will all use the same array of indices and show 
the same order of elements, the same permutation.
Because of this mutable nature of some ranges it's important to 
understand in which order calls to .front and .popFront() happen. 
The array() function calls popFront on its input in  a loop, 
consuming the mutable ranges, while map() does not. So in
  r.map!f.array
function f will receive different valid values, before they get 
invalidated in the loop of array(). But if they contain 
references to something mutable, it makes sense to make copies 
before the thing they refer to mutates.