earthquake changes of std.regexp to come

[Andrei Alexandrescu]

Jarrett Billingsley wrote:
> On Tue, Feb 17, 2009 at 7:13 PM, Bill Baxter <wbaxter at gmail.com> wrote:
>> Ok.  I'm certainly not in love with the API either.  Though, the only
>> RegEx API I've ever used that felt totally comfortable with was
>> Perl's, which in large part is syntax instead of an API.  Python's
>> syntax I have to look over the documentation every time I use it, too.
>>  Maybe it's because of the "matching" vs "searching" distinction that
>> I find impossible to remember.
>> (http://docs.python.org/library/re.html)
>>
> 
> Is there ever a situation where you want to use a single regexp for
> both matching _and_ searching?  And if not, couldn't you just use ^ to
> anchor it?  I never understood why Python's API makes such a
> distinction.

Ehm, that's odd. You'd think that after Perl has set the precedent, it 
would be hard to do major goofs in designing a regex API.

By the way, the more I dig into std.regexp, the stiffer the hair on my 
neck gets. Get this: the API offers both global functions and member 
functions, with both RegExp and plain string arguments. The latter are 
carefully designed to maximize the number of clashes, potential 
confusions, and errors when using both std.string and std.regex.

But wait, there's more. The API defines the following functions that all 
ostensibly do some sort of mattern patching (sic): find, search, test, 
match, and exec. I wish I were kidding. There's some opIndex and 
opEquals thrown in for good measure. Knuth wouldn't know what each of 
them does after studying them for a week and then watching an episode 
from "The Bachelor". And get this: global search() does not do what 
member search() does. Nope. Global search() does what member test() 
does. I have only contempt for such designs.


Andrei