I'm back

[Jonathan M Davis]

On Wednesday, November 14, 2012 20:18:26 Timon Gehr wrote:
> That is a very imprecise approximation. I think it does not cover any
> ground: The day eg. 'array' will require this kind of non-transient
> element range is the day where I will write my own.

std.array.array _cannot_ work with a transient front. It's stuffing the elements 
into an array as iterates over them, and if each of those elements keeps 
changing on it, then it won't end up with the right result. I don't believe 
that there is any way around this, not without somehow duping front when 
necessary, but we have no way to do that generically, and even if we did, 
there's no way for std.array.array. to know whether front is actually 
transient or not, just whether it _might_ be - not without the range having a 
property of some kind which told you that its front was transient. So, 
automatically duping would just introduce inefficiencies, because it couldn't 
know when it actually needed to do it or not. Something like

auto arr = array(map!"a.dup"(file.byLine()));

would work, but as long as ByLine reuses its buffer, it will _never_ work with 
std.array.array. std.array.array is _precisely_ the sort of range that would 
require the restrictions that Andrei is talking about. We either need restrictions
like that, to complicate ranges in general with extra traits and/or functions which
support transience, or to make transient fronts outright invalid ranges.

- Jonathan M Davis