On Tuesday, July 10, 2012 08:54:18 Jacob Carlborg wrote: > On 2012-07-09 23:00, Timon Gehr wrote: > > Actually you need a random-access range with assignable elements. Map > > would need to be provided with an inverse mapping to support that. > > > > zip has assignable elements when the source ranges do. > > Are you saying I can't sort a range that comes from "map"? To me it > seems like std.algorithm and ranges are a complete failure.
It's a complete failure because not every range works with every range-based function? We have isInputRange, isForwardRange, isRandomAccessRange, hasSlicing, etc. for a reason. Different ranges have different capabilities, and different algorithms generate different types of ranges based on what they do. For instance, filter cannot possibly have slicing, because it's on O(n) operation to determine which elements match the predicate. You have to iterate through _all_ of the elements. Rather than doing that (and therefore not working with infinite ranges and being inefficient with non-infinite ranges), it's lazy, and if you _do_ want to process all of the elements to know filter's length and therefore make it slicable, you generate a new range from it - generally with std.array.array. map is in the same boat. It has to generate new range type, and the choice is between being lazy and efficient (and therefore require a call to array) or being inefficient and calling array internally. - Jonathan M Davis
