DMD 0.170 release

[Walter Bright]

John Reimer wrote:
> Ah, ok.  I stand corrected on that aspect of my critique.

I'll give some more lame justifications:

There's been some talk about Boost recently in the n.g. (here and in 
comp.lang.c++) about if what Boost does is really worth it, or if it's 
just a lot of show-how-clever-I-am falderol. The general idea among the 
Boost people is that if there's any way possible it could be done in a 
library, rather than the core, then that's the way it should be done.

I don't agree with that idea. I think Boost stretches C++ past the 
breaking point, and rather than showing how powerful C++ is, shows 
instead that the C++ core lacks power. Some of the shortcoming 
workarounds in Boost are just incredible, in the dogged persistence of 
their inventors to somehow make them work. Even so, the Boost results 
still wind up with serious holes in them.

If some crucial features are added to the core language, then much of 
Boost either becomes irrelevant, or at least becomes far simpler and 
straightforward to implement.

So let's take a simple example, not from Boost, but from its earlier 
incarnation STL. STL has an algorithms section, and one of those is 
for_each. A glaring shortcoming of for_each is you have to supply a 
function pointer to it - you cannot just supply a statement in { }. With 
foreach as a supported core language statement, it can be made to work 
in the general case, and it can be made to generate relevant error 
messages when used incorrectly. foreach is so darned useful, it seems a 
shame to have to do it with clumsy, limited hacks like std::for_each.

STL generalizes iteration across a collection using a special iterator 
type. One needs to be created for each collection class. The iterators 
are then used in the implementation of STL algorithms. There are 3 kinds 
of iterators: forward, reverse, and random access. There's a serious 
problem with iterators, though - they require the collection to be 
accessible in a serialized way, when many data structures (such as 
binary trees) are not easily traversed that way (recursive descent for 
them).

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.