> 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