On Monday, 3 June 2013 at 02:31:00 UTC, Andrei Alexandrescu wrote:
On 6/2/13 2:43 PM, monarch_dodra wrote:
I think I just had a good idea. First, we introduce "cached":
cached
will take the result of front, but only evaluate it once. This
is a good
idea in and out of itself, and should take the place of
".array()" in
UFCS chains.
Yah, cached() (better cache()?) should be nice. It may also
offer lookahead, e.g. cache(5) would offer a non-standard
lookahead(size_t n) up to 5 elements ahead.
Hum... That'd be a whole different ballpark in terms of power, as
opposed to the simple minded cached I had in mind.
But I think both can coexist anyway, so I see no problem with
adding extra functionality.
From there, "tee", is nothing more than "calls funs on the
front
element every time front is called, then returns front".
From there, users can user either of:
MyRange.tee!foo(): This calls foo on every front element, and
several
times is front gets called several times.
MyRange.tee!foo().cached(): This calls foo on every front
element, but
only once, and guaranteed at least once, if it gets iterated.
I kinda dislike that tee() is hardly useful without cache.
Andrei
I disagree. One thing a user could expect out of tee is to print
on every access, just to see "which elements get pushed down the
pipe, and in which order", as opposed to "just print my range".
In particular, I don't see why tee would not mix with random
access.
For example, with this program:
auto r = [4, 3, 2, 1].tee!writeln();
writeln("first sort (not sorted)");
r.sort();
writeln("second sort (already sorted)");
r.sort();
I can see the output as:
first sort (not sorted)
2
1
1
2
1
3
1
1
3
2
2
1
2
4
1
1
4
2
2
1
3
3
2
3
2
1
3
2
4
3
second sort (already sorted)
3
4
3
2
3
2
1
2
1
2
1
3
2
4
3
which gives me a good idea of how costly the sort algorithm is.
It's a good way to find out if cache(d) or array should be
inserted in my chain.
