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
