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

[Marco Leise]

Am Sat, 14 Dec 2013 16:38:20 +0100
schrieb "Joseph Rushton Wakeling"
<joseph.wakeling at 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