<div class="gmail_quote">On Thu, Dec 31, 2009 at 16:47, Michel Fortin <span dir="ltr"><<a href="mailto:michel.fortin@michelf.com">michel.fortin@michelf.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 2009-12-31 09:58:06 -0500, Andrei Alexandrescu <<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>> said:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The question of this post is the following: should output ranges be passed by value or by reference? ArrayAppender uses an extra indirection to work properly when passed by value. But if we want to model built-in arrays' operator ~=, we'd need to request that all output ranges be passed by reference.<br>
</blockquote>
<br></div>
I think modeling built-in arrays is the way to go as it makes less things to learn. In fact, it makes it easier to learn ranges because you can begin by learning arrays, then transpose this knowledge to ranges which are more abstract and harder to grasp.<br>
</blockquote><div><br>I agree. And arrays may well be the most used range anyway.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Beside, an extra indirection is wasteful when you don't need it. It's easier to add a new layer of indirection when you need one than the reverse, so the primitive shouldn't require any indirection.</blockquote>
<div><br>So (squint through sleep-deprived eyes:) that makes it by ref, right?</div><div> <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
// pseudo-method<br>
void put(R, E)(ref R tgt, E e) {<br>
tgt.front = e;<br>
tgt.popFront();<br>
}<br></blockquote></div></blockquote><div><br>A few random comments, sorry if they are not entirely coherent:<br><br>- this new put needs hasAssignableElements!R, right? What's in this case the difference between isOutputRange!R and hasAssignableElements!R?<br>
<br>- should all higher-order ranges expose a put method if possible? (stride comes to mind, but also take or filter).<br><br>- does that play nice with the new auto ref / ref template parameter from 2.038? It seems to me that this new feature will go hand in hand with this, but I may be mistaken.<br>
<br>- your shim method will be used like this:<br><br>put(r,e);<br><br>whereas for an output range you use:<br><br>r.put(e);<br><br>and you cannot freely go from one form to the other, except for arrays, which are output ranges anyway [*]. Does that mean that you must disseminate static if ByRef/Assignable/Output/Whatever checks everywhere, to use either put(r,e) or r.put(e)?<br>
<br>- what if R is a range of ranges (ie: if E is itself a range). Should put by invoked recursively? What if its a chunked range?<br><br>
- something I wanted to ask for a long time: does put really write to
the range as written in the docs or to the underlying container for which the output range is but a
'writable' view? The container/range separation does not exist for arrays, but is important for other cases.<br><br><br> Philippe<br><br>[*] except if this transformation rule is implemented now?<br></div></div>