Andrei Alexandrescu napisał: > 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.
On the stack, for loops do it for years. -- Tomek
