Re: [boost] Formal Review: Boost.RangeEx

Subject: Re: [boost] Formal Review: Boost.RangeEx
From: Rogier van Dalen (rogiervd_at_[hidden])
Date: 2009-02-27 13:43:06

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.

Cheers,
Rogier