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