Re: [boost] Formal Review: Boost.RangeEx

Subject: Re: [boost] Formal Review: Boost.RangeEx
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2009-02-27 12:20:45

On Fri, Feb 27, 2009 at 5:33 PM, Thorsten Ottosen <nesotto_at_[hidden]> wrote:
> Rogier van Dalen skrev:
>>
>> Dear Neil,
>
>>> 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.
>
> I tend to agree.
>
> E.g. an algorithm like transform(-) should return a range.
>
> Or perhaps we need a new syntax to enable
>
>  rng && rng2 | transformed(binary_fun())

you mean for the two ranges variant of transform?

Well first you can always do this:

  zip(rng, rng2) | transformed (unpack(binary_fun())

obviating the need for a 2 range (or n-range) variant at all.
Otherwise, may be an infix syntax would work (but it probably count as
too much operator abuse [1]):

 rng1 ^transformed(binary_fun())^ rng2  ;

Distinguishing from the 1 range and 2 range variants would be
interesting. It might work better for 2-ranges only adaptors:

  (rng1 ^merge^ rng2)

[1] FWIW, FC++ has generalized infix function object with the same syntax.

-- 
gpd