front evaluated multiple time with joiner depending on where extra arg given

[Timothee Cour]

>
>
> Certainly, I'd argue that it's generally better practice to do the work
> in popFront, because front does frequently gets called multiple times, and
> you
> almost always end up calling front if you call popFront.
>

Actually, the way phobos is designed, often times it's easier to specify
what front does, eg with map and related functions.


>
> It's possible that map, joiner, and or array could use some efficiency
> improvements, but I wouldn't consider the difference in the number of
> calls to
> front to be a bug. At most, it might indicate that there are some
> optimization
> opportunities in one or more of those functions, and it might even be that
> the
> differing number of calls makes sense when you actually dig into the source
> code. I'd have to go digging to know for sure.
>


it's not just an issue of optimization opportunities, it's an issue of
correctness and principle of least surprise; the code I shown was simplied
from a larger bug I had where I was doing side effects in the map lambda
that were meant to be called once per element instead of multiple times.

Is there a convenient to achieve the same effect as this:

elements.map ! fun_with_side_effects . joiner . do_something_with_result

but such that fun_with_side_effects is called only once per element ?
(likewise with other functions that operate on ranges).

As it is, joiner and friends is dangerous to use with generic code because
of that. std.array.{array,join} doesn't have this issue.

why not modify joiner (+friends) so that:
if front() is pure, allow calling it multiple times
if not, make sure to call it only once per element
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20131022/4a2379d2/attachment.html>