Re: RFC 166 (does-not-match)

> This is going to need a much better definition...

Yes, that was my point.

I snipped the following discussion, in which you argued against a
suggestion that I advanced only as an example of something that would
not work.

> (?^baz) should behave as (.*)(?{$1 !~ /baz/})

I don't think that's going to do it.  Consider this pattern:

        /foo(?^baz)baz/        

Here I am trying to match strings like "foobarbaz" and "foo---baz"
that have a foo and a baz separated by something else that is not a
baz.  But with your definition, 

        "foobazbaz" =~ /foo(?^baz)baz/        

is true, when I wanted it to be false.  This is because the (?^baz)
matches the empty string after the 'o', and the "baz" in the pattern
matches the first baz in the string, instead of the second one.  

> I think one should outlaw .* before or after a (?^foo) construct, as
> the result is meaningless.

As it stands now the whole notion is meaningless, because you have not
given it a meaning.  

Can you provide a detailed explanation of just what is and what is not
outlawed?  I presume that .+ is also forbidden.  What about a*, .?,
.{3}, etc.?

I wonder if this restriction is really necessary?

> I can tighten the definition up.  If there have been calls for a 
> (?^baz) type construct before, there will be again.  It is a matter of
> getting the definition straightforward and useable.

Yes, I agree completely.  I am looking forward to the next version of
your RFC.