> If I had
>
> int f( int );
>
> boost::for_each( vec | boost::adaptors::reversed | boost::adaptors::uniqued,
> f );
>
> and instead were able to write it as
>
> vec | boost::adaptors::reversed | boost::adaptors::uniqued | f;
>
> the final use of operator|() seems to pretty much imply eagerness in the
> same way that the for_each() does.

Only if you happen to know that f is a function and will be treated
completely differently from the range adaptors.

Ignoring the implementation issues for a moment I would like to explain my rationale for the current syntax. I consider the range adaptors to be orthogonal to algorithms. I therefore perceive a syntactic difference between the application of algorithms and adaptors to be an advantage. With your example above I find the first version of the code more instantly understandable since the most-significant operation (copy) is at the start of the line. Therefore my personal opinion is that it is undesirable to extend the pipe syntax to the application of algorithms.

Now considering implementation details I believe there are other reasons to not extend the pipe syntax. When designing Boost.Range the extension of the central idioms to user types and algorithms has been made simple. The range adaptors are less simple to implement but are far less numerous than user supplied algorithms. The current arrangement provides an extremely low barrier for users wishing to implement range based algorithms.

I am very interested to hear the thoughts of yourself and the rest of the boost community now that I have expanded upon some of the rationale. I am open to being convinced.

- Rob.

Regards,

Neil Groves