dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
[snip]
I absolutely love it!  Frankly, the convenience of std.algorithm is the greatest
thing since sliced arrays, but all the memory allocation is sometimes pretty
inefficient, so I end up coding lots of stuff at a lower level to avoid this.  
One
thing, though, is that I would like to see eager() know whether whatever it's
eager-izing has a predetermined length, and if so, what that predetermined 
length
is, so it can get by with a single allocation.

Great. Fortunately that will be elegantly supported by the range design: if the range passed to map supports .length, the range returned by map will also support it (and the implementation will simply do the forwarding). Consequently, eager will detect a range that also supports .length, in which case it only does one allocation.

Gotta love static if and is(expression). For years people didn't even know whether or not it's possible to detect (in C++) the existence of a member, let alone the validity of an arbitrary expression. Today detecting the existence of a member is possible but in a very inconvenient and limited manner.

As far as the confusingness of
lazy evaluation, it might take some getting used to, but the really hard cases
could be solved by just using eager() anyhow, and we wouldn't be any worse off
than if lazy weren't supported.

Really, the only downside I see is slightly clumsier syntax when eager 
evaluation
is needed.  IMHO, this could be improved if eager() were, at least 
syntactically,
a property of ranges, for example:

map!("a * a")(arr).eager();

How about dropping those parens :o).


Andrei

Reply via email to