Re: [boost] [Range] Range adaptor approach for temporary range lifetime issue

Subject: Re: [boost] [Range] Range adaptor approach for temporary range lifetime issue
From: Michel Morin (mimomorin_at_[hidden])
Date: 2012-07-06 07:31:32

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