On 04/09/2013 10:37 PM, H. S. Teoh wrote: > Congratulations! You've created your first transient range. :)
:-) Well, the problem isn't transience per se. It's acceptable that popFront() overwrite previous returned values -- the problem is strictly that in deciding that the range is empty, the 'last' value is overwritten. > Personally, my preference is to let the user code call .dup to copy the > value instead of aliasing it. The crux of the issue is that returning an > array is by reference, so it's equivalent to returning a reference. If > you were calling a ref function, you'd be careful about assuming whether > its value would change afterwards. The problem is that the range API > conflates by-ref and by-value .front's, and there's currently no way to > tell them apart aside from knowing the specifics of the range you're > dealing with. I'll give the take-by-dup rather than return-by-dup option a go just to see if it can work. Unfortunately in practice it's a bit more complex because some of my use cases might want to return a more complex data structure than just an array (e.g. a struct containing one or two arrays and some values). Thanks for the thoughts and especially for the in-depth explanation on transience! :-)