couple of really noob questions (ranges, toString)

[Jonathan M Davis]

On Tuesday, November 02, 2010 04:16:58 spir wrote:
> On Mon, 1 Nov 2010 20:40:30 -0700
> 
> Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > The term "pop" does _not_ mean that an element is returned but that it is
> > removed from the range. This is true for pretty much anything that uses a
> > pop function in any language - stacks, lists, etc. It _is_ true that
> > many implementations choose to have pop return the element which is
> > popped, but that's an implementation detail. The term pop merely
> > indicates that an element is removed from an end of a range or
> > container.
> 
> All right, that's where I went wrong. Thank you for the clear explanation.
> (Now, I will continue with the article by Andrei Alexandrescu, 10 pages
> left :-)
> 
> [But I do not know of any pop not returning the removed value in any lang
> or library; instead, pop is the favorite example of people arguing against
> the distinction between actual functions (result, but no effect) and
> actions (effect, but no result): naughty pop does both. Maybe call it here
> remove()? Even if "pop"'s sense was defined by an all-mighty authority, we
> could hardly avoid people having different expectations born from previous
> experience, esp when it's so widespread: the two pop examples at
> http://en.wikipedia.org/wiki/Stack_%28data_structure%29 return the
> element.]

C++'s pop functions don't return anything either, but it is true that many 
libraries in many languages choose to have pop functions return the value which 
is being popped. Having popFront() return a value in addition to having front 
look at the first value in the range wouldn't necessarily be a problem, but it 
isn't strictly speaking necessary. In some languages (certainly C++, though I'm 
not sure about D), returning a value which isn't used can mean a wasted copy or 
object construction which can be inefficient (particularly when dealing with large 
objects on the stack). Whether a pop function returns anything tends to depend 
on how much an efficiency concern the library writer thinks that it is and how 
likely they think that it is that the popped value is going to be wanted. If 
it's expected that someone will always want the popped value, then it can be 
quite nice to have the pop function return it, but if there's a good chance that 
they won't, then it could be an unwanted inefficiency. It all depends on the goals 
and concerns of the library writer. In this case, D chose to not have popFront() 
return anything.

> I would also find current() much clearer than front(), since from the
> client's perspective it looks like shrinking the collection (or view)
> instead of traversing it; see the confusion expressed by the OP's original
> question; but well...

Except that unlike an iterator (which indicates a single element), a range 
indicates a range of elements, so it can have both a front and a back (similar 
to having two iterators indicate a range of elements), so current() would be 
highly confusing once you went beyond input or forward ranges. For instance, bi-
directional ranges have back and popBack(), and random-access ranges have the 
subscript/slicing operator which can access an element or range of elements in 
the range, so current() would become highly confusing. What you have is a range 
of elements which has a clear first element (and assuming it isn't infinite or of 
indefinite length) a clear last element. So, front and back access them and 
popFront() and popBack() pop them. It is indeed generally a view of a collection 
of elements, but there is a definite order to them, whereas current() does not 
indicate order.

- Jonathan M Davis