On 1/21/11 7:35 PM, Tomek Sowiński wrote:
Andrei Alexandrescu napisał:
Like I said, anything that doesn't bother to expose range-interfaced iterators
and is not performance critical is
considered a target for ad hoc ranges. Working with non-D libraries, or
libraries ported to D but preserving
mother-language idioms. Tasks like traversing a tree of GUI widgets, or
business specific objects where defining
proper ranges rarely happens and is use-case driven in practice. I expect they
could be of some use in unittesting
as mock input. Vaguely related: educational -- ad hoc ranges read almost like a
for loop so the learning curve for
ranges in general is eased off.
Adding them to Phobos is an interesting idea. We need to evaluate their worth,
though.
Everybody: if you could write up a one-liner like range(empty, popFront,
front), what would you use it for?
How about a singleton range - a range with exactly one element. It could
be done with repeat(x, 1) but let's try it with your function as a
warm-up exercise.
If x is nullable, range(x, x=null, x); it destroys x, though. Otherwise the
state must be held separately on the stack.
bool empty;
auto r = range(empty, empty=true, x);
So repeat(x, 1) wins this one. I think such nuggets can better be expressed as
a degenerate case of existing facilities. I envision ad hoc ranges at places
where no iteration is defined and a one-off range struct doesn't pay. Like
database-backed entities which don't conform to any clear-cut data structure,
but if you squint you see it's sort of a tree, and you may just be able to e.g.
walk through children recursively fetching only active ones from DB, traverse
columns of interest, and dump their content to a grid component which takes an
arbitrary range of values. And all this can be wrapped in std.parallelism to
overlap DB round trips.
I think the challenge here is to figure out where to store the state.
The idiom makes it difficult for the delegates to communicate state to
one another.
Andrei
