earthquake changes of std.regexp to come

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> I'm quite unhappy with the API of std.regexp. It's a chaotic design that
> provides a hodgepodge of functionality and tries to use as many synonyms
> of "to find" in the dictionary (e.g. search, match). I could swear
> Walter never really cared for using regexps, and that is felt throughout
> the design: it fills the bullet point but it's asinine to use.
> Besides std.regexp only works with (narrow) strings and we want it to
> work on streams of all widths and structures. One pet complaint I have
> is that std.regexp puts a class around it all as if everybody's favorite
> pastime would be to inherit Regexp and override some random function in it.
> In the upcoming releases of D 2.0 there will be rather dramatic breaking
> changes of phobos. I just wanted to ask whether y'all could stomach yet
> another rewritten API or you'd rather use std.regexp as it is for the
> time being.
> Andrei

As I've said before, anyone who can't stomach breaking changes w/o complaining has
no business using D2 at this point.  I'd rather deal with the aggravation of stuff
breaking in the sort run to have a nice language and libraries to go with it in
the long run.

This whole concept of ranges as you've created them seems to have achieved the the
holy grail of both making simple things simple and complex things possible, where
"complex things" includes needing code to be efficient, so I can see your reason
for wanting to redo all kinds of stuff in them.  This compares favorably to C++
STL iterators, which are very flexible and efficient but a huge PITA to use for
simple things because the syntax is so low-level and ugly, and to the D1/early D2
way, which gives beautiful, simple notation for the more common cases (basic
dynamic arrays), at the expense of flexiblity when doing more complicated things
like streams, chaining, strides, etc.