Re: [boost] Formal Review: Boost.RangeEx

Subject: Re: [boost] Formal Review: Boost.RangeEx
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2009-02-25 11:21:57

On Wed, Feb 25, 2009 at 5:00 PM, Neil Groves <neil_at_[hidden]> wrote:
> Dear Sir,
>
> On Wed, Feb 25, 2009 at 3:36 PM, Rogier van Dalen <rogiervd_at_[hidden]>wrote:
>
>> On Fri, 2009-02-20 at 13:28 +0100, Thorsten Ottosen wrote:
>> > Dear Developers and Users,
>> >
>> > It's my pleasure to announce that the review of Neil Groves' RangeEx
>> > library starts today and lasts until March 3, 2009.
>>
>> That's great news! I've much anticipated this library, since I'd
>> hand-rolled similar components a long time ago. I hope to submit a
>> formal review, but before I do, I hope to understand the motivation for
>> the design better. I hope this is allowed within a formal review. This
>> is related to my question at
>> <http://lists.boost.org/Archives/boost/2008/07/140514.php>.
>>
>> I am not sure I understand the motivation for the operator| syntax. Why
>> couldn't
>>        vec | boost::adaptors::reversed | boost::adaptors::unique
>> be written
>>        boost::adaptors::unique (boost::adaptors::reversed (vec))
>> ? I think this contrast would be fairer than what the documentation
>> currently has. Is there a reason why it is not possible to provide both
>> syntaxes? The pipe syntax is nice, but sort of restricts operations to 1
>> range in, 1 range out. Relatedly:
>>
>
> In the adaptors section the preference for operator| is documented. It
> simply chains better in my opinion.
>
> I do provide both alternatives, for example
>
> boost::make_uniqued_range(rng) is equivalent to rng | uniqued
>

IMHO the make_... syntax for range adaptors is horrible (i don't even
like the past tense, why not just unique?).
But why use two different names in the first place? Why not make

'some_functor(range) ' eqivalent to 'range | some_functor'

(i would actually go for the syntax 'range | some_functor(_r)', where
_r is a placeholder for the range; This is usefull for adaptors that
actually have other parameters in addition to the range itself)

-- 
gpd