On Thursday, 24 October 2013 at 19:50:44 UTC, Jonathan M Davis
wrote:
On Thursday, October 24, 2013 21:10:58 deadalnix wrote:
On Thursday, 24 October 2013 at 17:57:54 UTC, Jonathan M Davis
wrote:
> Now, that being said, I'd argue that map should probably be
> changed so that it
> calls its function on popFront rather than front (though that
> has the downside
> of requiring that it then hold the current value, which it
> doesn't currently
> have to do), but regardless, you're using map for something
> other than what it
> was designed to do.
That would break random access.
No, it wouldn't. It would just require that the function be
called directly in
the case of random access, so you then have the problem with
randomly accessed
values that you really can't implement map in a way that avoids
a calling its
function every time you randomly access a variable. It's one
more reason to
consider not accessing the same element in a range multiple
times, but as it's
pretty much a guarantee that at least some range-based code
will access front
multiple times, it's not a good idea for the range to be
designed such that it
can't reasonably handle having each element accessed multiple
times - which in
the case of map would imply that the programmer using map
should make sure
that the function they give it can handle being called multiple
times per
element without changing the semantics of the code. It also
would imply that
doing something like
range.map!(a => new Aboject(a))
like you do in another post should be done with great care if
at all, as there
is a high risk that you will end up creating multiple objects
per element as
you traverse the range unless you specifically make sure that
use foreach on it
or immediately convert it to an array.
- Jonathan M Davis
OK let me restate : it would give random access a different
semantic than in order access. Which is undesirable.
