Sergey Gromov wrote:
Mon, 12 Jan 2009 17:38:40 +0000 (UTC), dsimcha wrote:
== Quote from Sergey Gromov (snake.sc...@gmail.com)'s article
Mon, 12 Jan 2009 09:05:18 -0800, Andrei Alexandrescu wrote:
Also, lazy evaluation has the risk of getting confusing as there's a lot
of escaping. Consider:
int[] arr = [ 1, 2, 3, 4 ];
auto squares = map!("a * a")(arr);
arr[] = [ 5, 6, 7, 8 ];
Now iterating squares will see different numbers than the original ones.
This part bothers me. Though it's hard to tell how much danger it would
impose in practice.
I don't understand how this is any worse/more confusing than any other case of
having multiple aliases to the same memory region.
First, it's an obscure alias. Second, it wasn't so in the previous
implementation of std.algorithm. OTOH these are mitigated by the fact
you're going to re-visit the map!() usage in your code anyway.
Correct. Besides, laziness enables programming patterns and styles that
are very useful. For example, after the overhaul of std.algorithm, a
plethora of generators will come forth.
Also I've got an impression that Phobos tried to avoid dangerous
aliasing as much as possible by using immutable argiments in aliasing
algorithms. map() obviously refuses to follow this rule.
Well it doesn't "refuse" as that suggests confrontation. It simply
acknowledges that oftentimes map's functionality is useful over mutable
inputs.
On an unrelated note, I probably should make a post about Phobos
overusing immutable arguments. This is a direct consequence of
declaring string as an alias of immutable(char)[] which is IMHO plain
wrong.
This shapes up as a basic disagreement, but to a large extent we can
work things out. For example, a generic string function such as
startsWith(someString, prefix) should not require invariant inputs when
it could work just as well for mutable arrays. Then everybody is happy.
Andrei
