Boost logo

Boost :

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


> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at