Re: [boost] Formal Review: Boost.RangeEx

Subject: Re: [boost] Formal Review: Boost.RangeEx
From: Rogier van Dalen (rogiervd_at_[hidden])
Date: 2009-02-26 08:09:52

On Wed, 2009-02-25 at 23:01 +0100, Giovanni Piero Deretta wrote:
> ( BTW If you decide to adopt this solution, I suggest putting the
> range parameter last. This way It would sort of simulate the automatic
> currying syntax of some functional languages (where omitting the last
> m parameters of n-arity function makes it a higher order function that
> returns an (n-m) arity function. )

Surely to get a currying effect, you'd put the range parameter first? Or
am I misremembering my functional programming classes?

> This approach has unfortunately a big problem. If you have adaptors
> with optional arguments, without concepts it is an iteresting problem
> figuring out which overload the user wants:
> 
>    merged(r1, r2);  // uses operator< as comparator
>    merged(r1, r2, cmp); //  uses cmp as comparator
>    r1 | merged(r2, cmp); // interesting problem here!
>    r1 | merged(_r, r2, cmp); // much better
>    r2 | merged(r1, _r, cmp); // we have a choice of the argument to bind
>    r1 ^merged(_r1, _r2, cmp)^ r2; // probably beyond the scope of the library ;)
> 
> In my code, I use '_' as a placeholder, instead of '_r'.

Much as I hate to say it, this is an argument for naming function-style
and operator|-style adaptors differently. But isn't it possible to use
SFINAE to disambiguate? Rng::iterator would exist and Cmp::iterator
wouldn't, right?

Cheers,
Rogier