<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 24, 2013 at 12:50 PM, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thursday, October 24, 2013 12:14:27 Timothee Cour wrote:<br>
> so far you've emphasized on the fact popFront should take care of all side<br>
> effects and front should be logically pure and fast to compute, but you<br>
> haven't suggested any alternative for what I'm trying to achieve.<br>
><br>
> In what I propose it's generic (works in all cases) and simple (just add<br>
> ".cacheFront" after a lambda with side effect):<br>
><br>
> auto test(T)(T elements) if(isInputRange!T){<br>
> return elements<br>
> .map!( (a) {preaction(a); auto b=transform(a); postaction(a,b); return b;})<br>
> .cacheFront<br>
> .filter!foo; //or joiner or....<br>
> }<br>
><br>
> So, how do you achieve the above without using cacheFront, without creating<br>
> a _custom_ range or writing a lot of code ?<br>
> I don't see how using foreach is a good idea (ForEachType!=ElementType, it<br>
> doesn't reuse phobos functionality and doesn't play well with phobos range<br>
> functions)<br>
<br>
</div>If you don't want to do this with foreach</blockquote><div><br></div><div>foreach is not lazy, so not an option</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
, then creating a custom range is exactly what you should be doing, </blockquote><div><br></div><div>why make user reimplement the wheel each time with a custom range when a generic solution (such as above, maybe could be improved) works ?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and the logic for the pre and post operations should go in popFront. </blockquote><div><br></div><div>how can a *pre*-operation go in popFront, which occurs *after* front (without significant gymnastics) ?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Having side effects in front is just begging for problems, and it's not at all what map is designed for. And honestly, if<br>

your popFront isn't pure as well, and the side effects that you're doing affect<br>
something outside of the range, then I would suggest that you not use ranges<br>
for what you're doing, because that violates their functional nature. </blockquote><div><br></div><div>That's an arbitrary restriction. I've faced many situations where I could use the full power of range based algorithms while not restricting myself to purely functional code (necessary side effects). With proper care it can be done. Again, no need to reimplement standard algorithms just because of some impure lambdas.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It has been proposed before that a function be added to Phobos which did an<br>
operation when iterating over an element, in which case that operation would<br>
go in popFront, and front would just return the wrapped front. That would<br>
probably get you what you want and be more generally applicable than<br>
cacheFront.<br></blockquote><div><br></div><div>Are you referring to proposals for tap ? There were many proposed, so not sure which one you're mentioning. Or something else?</div></div></div></div>