DMD 0.170 release

[Bill Baxter]

Walter Bright wrote:
> John Reimer wrote:
>> Ah, ok.  I stand corrected on that aspect of my critique.
> 
> I'll give some more lame justifications:
> ...
> So I've been interested in having D algorithms and collections not need 
> iterator types at all. I've been experimenting with doing STL's 
> algorithms in D, and it became clear that to make them complete, reverse 
> iteration was necessary. foreach handles forward iteration, and opIndex 
> handles random access. Various ways of doing reverse traversal without 
> core support always seemed to involve creating dummy classes and other 
> hackish stuff. Promoting it to a supported statement makes it pretty 
> clean for the user to understand and use.
> 
> Essentially, I think foreach_reverse is the missing piece to be able to 
> implement all of STL's algorithms code for D.

I don't see how it helps.  If you can already do:
    foreach(T item; &collection.reversed()) { }

isn't that alone enough to be able to implement all of STL's algorithms 
without adding a "foreach_reverse"?

In fact I'd argue that adding foreach_reverse does nothing more to make 
STL algorithms implementable.  If I'm trying to implement something like 
std::copy, how is foreach_reverse going to help me do that generically? 
  Users can't pass 'foreach_reverse' in as an argument if they want to 
make a backwards copy of something.  But they can certainly pass 
&collection.reversed() in as one.

And -- wouldn't it be nice if the original designer of the class forgot 
to write a reversed(), if I could write one and do
    foreach(T item; reversed(collection)) { }
(without dummy classes and hackish stuff being required). :-)

--bb