Re: [Boost-users] Limitations / Flaws with transformed_range

I've found another issue, and I consider it a "flaw" because it is a Limitation due to oversight or an artificial restriction, and the deeper workings should handle these cases just fine. Let me explain in detail:

The template< class F, class R > struct transformed_range :

takes two arguments. The R argument is used for two purposes. It gives the iterator type that will be held, via range_iterator<R>::type. It also gives the exact type of the argument expected by the constructor.

Now here is an example from my experiments / work-in-progress:

template< class Range > inline transformed_range operator|( const Range& r, const ASCII_lower_forwarder ) { return transformed_range( ASCII_lower(), // The underlying transform iterators wants this internal::src_prep(typename std::tr1::is_pointer<Range>::type() ,r) // "source" style argument processing ); }

The src_prep is similar to the supplied is_literal, and used for the same purpose. It will package a primitive array as a iterator_range, handing string literals and primitive array objects in the way I intend with respect to nul terminators. It differs from is_literal in several ways, but the idea is the same.

Now I don't have to do anything to the Range parameter passed as the type argument to transformed_range, because even when I change the type of the massaged argument, it still has the same underlying iterator type. After all, it gets the iterators from the original range thing passed in.

But, the massaged value of r is rejected by the constructor, because it has a different type. It doesn't need to be the same type! It has the same underlying iterator type and could be assigned to it, but the constructor is too strict.

I don't think this "operator|" - which lives in the boost::range_detail namespace (note the "detail") - is meant to be specialized by users. Why not accomplish this "massaging" through your own range adaptor instead? As in: my_range | my_massager | transformed(ASCII_lower()) If you use this a lot, you could write a range adaptor that combines the two: my_range | ascii_lowered Regards, Nate.