Neil Groves wrote:
If we are pushing the laziness to the extreme whereby the begin()/end() calls create the iterators we are also changing the exception semantics be delaying throws. I therefore tend to think that we would be better having lazy range adaption by the adaptors creating a class convertible to a range that captures and hence triggers the adaptor evaluation via implicit conversion. I proposed this on the list a few weeks ago. I see no reason to break backward compatibility by loosening the performance guarantees of begin()/end().
Ah, now I understand what you're trying to do. You're controlling the timing of range adaptor invocation for lazy implementation, right? For example, in the following code with your proposed implementation, reversed_range<...> rng = xxx | reversed; reversed range adaptor is invoked when lazy adaptor `xxx | reversed` is implicitly converted to reversed_range<xxx> `rng`, instead of when begin/end to `rng` is called. This solution does not work for auto-typed variables and function templates, since no implicit conversion is applied in those cases. So I think it would be better to provide a member function for explicit invocation of range adaptors auto rng = (xxx | reversed).eval(); or a range adaptor auto rng = xxx | reversed | eval; Regards, Michel