So why doesn't popFront return an element?

[Jonathan M Davis]

> On 04/14/2011 01:00 AM, Andrej Mitrovic wrote:
> > I'm trying to understand the design of ranges. Why does popFront only set
> > the front() property to return the next element in the range? Why not
> > return the element in the call to popFront right away?
> > 
> > For example code like this (which doesn't work since popFront doesn't
> > return): void main()
> > {
> > 
> > int[] a = [1, 2];
> > auto b = a.popFront;
> > assert(a == [2]);
> > assert(b == 1);
> > 
> > }
> > 
> > Isn't it wasteful to have to call both popFront() and front() to
> > simultaneously remove an element from a range and return it? I mean it's
> > an extra function call, right?
> 
> I like to have three members (even if not quite necessary, this cleanly
> separates notions). Why I don't understand is why empty and front are
> methods, not simple data members.

They're properties. They could be member variables or they could be member 
functions. It's up to the implementation of a particular range as to whether 
they're member variables or member functions, though they're likely to be 
member functions in most cases. In most cases, there wouldn't be any member 
variable corresponding to empty (more likely, it's a check against the length 
of the range or does something to determine whether there's more left in the 
range rather than being a member variable indicating whether the range is 
empty), and even with front, there could easily be a calculation of some kind 
or additional checks (e.g. to make it throw if empty is true) in front.

There is no requirement that front or empty be either functions or variables. 
They're properties, so they can be whatever makes the most sense for that 
particular range type. And as for arrays, they _have_ to be functions, since 
they're added by Phobos.

- Jonathan M Davis