Re: [boost] Formal Review: Boost.RangeEx

Subject: Re: [boost] Formal Review: Boost.RangeEx
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-02-27 14:07:06

----- Original Message ----- 
From: "Rogier van Dalen" <rogiervd_at_[hidden]>
To: <boost_at_[hidden]>
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_at_[hidden]> 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