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. -- Tomek
