Ezio Melotti wrote:
> Ezio Melotti <ezio.melotti@gmail.com> added the comment:
> 
> Also note that some behaviors are not "old" or "compatible", but just different.  For example why inline flags should be the old (or new) behavior?  Or e.g. the behavior of version 2 but not 0 and 1?
> Also what if I want zero-width splits but not nested sets and sets operations?  Or if I want inline flags but not zero-width splits?

I think this is adding excessive complexity. Please consider poor 
Matthew's sanity (or whoever ends up maintaining the module long term), 
not to mention that of the users of the module.

I think it is reasonable to pick a *set* of features as a whole:

"I want the regex module to behave exactly the same as the re module"

or

"I don't care about the re module, give me all the goodies offered by 
the regex module"

but I don't think it is reasonable to expect to pick and choose 
individual features:

"I want zero-width splits but not nested sets or inline flags, and I 
want the locale flag to act like the re module, and ASCII characters to 
be treated just like in Perl, but non-ASCII characters to be treated 
just like grep, and a half double decaff half-caf soy mocha with a twist 
of lemon with a dash of half-fat unsweetened whipped cream on the side."

<wink>

If you don't want a feature, don't use it.

"Feature flags" leads to a combinational explosion that makes 
comprehensive testing all but impossible. If you have four features 
A...D, then for *each* feature you need sixteen tests:

A with flags 0000
A with flags 0001
A with flags 0010
A with flags 0011
[...]
A with flags 1111

to ensure that there are no side-effects from turning features off. The 
alternative is hard to track down bugs:

"this regular expression returns the wrong result, but only if you have 
flags A, B and G turned on and C and F turned off."