Re: [boost] Formal Review: Boost.RangeEx

Subject: Re: [boost] Formal Review: Boost.RangeEx
From: David Abrahams (dave_at_[hidden])
Date: 2009-03-02 10:11:58

on Fri Feb 27 2009, Rogier van Dalen <rogiervd-AT-gmail.com> wrote:

> 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.

It breaks down once there's any interesting chaining:

   (r1 | f1 | f2) && (r2 | f3 | f4) && (r4 | f5 | f6) | merged

is no better than

   merge(r1|f1|f2, r2|f3|f4, r4|f5|f6)

I don't think that sort of range argument packing makes any sense at all
unless they have the same number of elements, in which case write

       zip(r1,r2,r3)

> 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?).

There appears to be a blind obsession with syntactic consistency at work
here.  Why else would we be groping about for infix ways to express such
an operation?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com