----- Original Message ----- From: "Rogier van Dalen" <rogiervd@gmail.com> To: <boost@lists.boost.org> Sent: Friday, February 27, 2009 7:43 PM Subject: Re: [boost] Formal Review: Boost.RangeEx
On Fri, 2009-02-27 at 16:54 +0000, Neil Groves wrote:
On Fri, Feb 27, 2009 at 4:33 PM, Thorsten Ottosen <nesotto@cs.aau.dk> wrote:
Rogier van Dalen skrev:
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.
I tend to agree.
I agree too, so this change shouldn't cause any disappointment to anyone!
Great!
E.g. an algorithm like transform(-) should return a range.
Or perhaps we need a new syntax to enable
rng && rng2 | transformed(binary_fun())
It seems that the '|' syntax is not much loved despite my deep affection for it. I am becoming inclined to concentrate more on the function syntax and just using the 'ed' convention.
Speaking for myself, I do "love" the | syntax, but I think it's non-standard and can't be used easily for other cases than single chains of operations (1 range in, 1 range out). I therefore suggest using 'verbed()' as the primary interface, and operator| as a secondary interface.
Two alternative spellings for merged(rng1, rng2) have been suggested.
1) (Thorsten) rng1 && rng2 | merged which I think is equivalent to rng1 && (rng2 | merged) It may be possible and useful to extend this to rng1 && rng2 && rng3 | merged I personally find the interaction between operator precedence and semantics scary, but maybe others feel different.
2) (Giovanni) rng1 ^merged^ rng2 which may be abuse, but it's nice. In the case of merged, rng1^merged^ rng2 ^merged^ rng3 would actually work. I'm not sure this works for all imaginable lazy range adaptors (zip?).
I can see how either would work as an additional syntax, but I'm not sure there's reason enough to impose the element of surprise that they carries by default.
I think something like zip() would be very useful, but for consistency should probably be spelled zipped(). zipped(rng1, rng2) | transformed (unpack(binary_fun()) seems more general for iterating through two ranges in parallel. zipped() would also alleviate the need for for_each over two ranges.
For consistency, why not pack(rng1, rng2) | transformed (unpack(binary_fun()) Vicente