Dear Neil, I just found that an email I wrote earlier never made it to the mailing list. I'll re-send it, at the risk of being late at the party. On Wed, 2009-02-25 at 16:00 +0000, Neil Groves wrote:
boost::make_uniqued_range(rng) is equivalent to rng | uniqued
I'm sorry for having been unclear here; I meant to ask why the spelling "make_ _range" is necessary (see Giovanni's email). To me, RangeEx provides functions that take a range and return a range. How is it not most natural to make these functions look like functions? What is wrong with saying "uniqued(rng)"? Why is it vital that the name has "make_ _range" to remind me that this returns a lazy range rather than a range?
I was hoping for more lazy views on ranges, especially after reading that the library allows for a "seamless funtional-style programming". Shouldn't there be a generated(), randomly_shuffled(), sorted(), intersected(), merged(), etc.? (I implemented lazy set operations implemented and I think it's quite possible.)
The library is intended to be extended both by myself as core needs become clear, and by library users. The algorithms, supported range types and adaptors may be implemented by users of the library without changing it.
Many lazy adaptors are desirable. I would continue to add more as time permits. My focus is on producing a good foundation for this version. The reviews are giving me a clearer need of what people want from the library.
Fair enough. This will be fine if many reasonable algorithms can be implemented within range_ex. However, could you state how you would integrate lazy merge() or anything that takes two or more ranges in operator| syntax? The function syntax would be: merged(rng1, rng2) I believe that the '|' syntax, however cute (I agree there!) is less flexible and less obvious than the function syntax. Therefore, I think the function syntax should be the primary one. Currently merge(), transform(), and the set algorithms use output iterators as a substitute for return values. Rephrasing them as functions would also get rid of output iterators, which would improve their interface. Thanks, Rogier