Ranges: is it ok if front is a data member?

[Jakob Ovrum]

On Friday, 13 December 2013 at 14:52:32 UTC, Marco Leise wrote:
> Am Thu, 12 Dec 2013 08:43:35 -0800
> schrieb "H. S. Teoh" <hsteoh at quickfur.ath.cx>:
>
>> I do this with my own ranges sometimes. Sometimes, it's more 
>> performant
>> to precompute the value of .front and store it (as .front), 
>> and have
>> .popFront compute the next value, than to have .front compute 
>> the value
>> every time. AFAICT, this is perfectly fine and should work 
>> with Phobos
>> seamlessly. The power of ducktyping!
>> 
>> 
>> T
>
> Most non-trivial ranges do the actual work in `popFront()' and
> return a cached value from `front'. It has been argued as a
> design quirk, that this in general leads to:

Really? I've never seen that particular pattern. I always just 
see the initial element being computed when the range is 
initialized, e.g. in a constructor or a constructor helper 
function.