On Saturday, 14 December 2013 at 15:26:36 UTC, Jakob Ovrum wrote:
> On Friday, 13 December 2013 at 14:52:32 UTC, Marco Leise wrote:
>> 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.

I don't know about "most non-trivial ranges" but it is a pattern that shows up when you have a struct that cannot be guaranteed to be properly initialized upon creation -- which is a common situation because structs don't allow a default constructor this().

Am Sat, 14 Dec 2013 16:38:20 +0100
schrieb "Joseph Rushton Wakeling"
<joseph.wakeling@webdrake.net>:

> On Saturday, 14 December 2013 at 15:26:36 UTC, Jakob Ovrum wrote:
> > On Friday, 13 December 2013 at 14:52:32 UTC, Marco Leise wrote:
> >> 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.
> 
> I don't know about "most non-trivial ranges" but it is a pattern that shows up when you have a struct that cannot be guaranteed to be properly initialized upon creation -- which is a common situation because structs don't allow a default constructor this().

I probably over-dramatized this from my own experience and a recent thread in digitalmars.D. Looking at some old code of mine I actually call .popFront() in a ctor where I thought I used a boolean flag. It's not a big deal in any case.

-- 
Marco