Quoth public@khwilliamson.com (karl williamson): > > The reason is that the code always outputs the modifier, even for the > the existing semantics, so the stringification is permanently different > from before. That got me to thinking that it should be possible to omit > the modifier from the stringification unless it is different from the > default. Thus backward compatibility would not be broken, although it > is a dangerous thing for modules to be relying on knowing all the > possible modifiers, and someone could pass them a regex compiled with a > new modifier that they don't know how to deal with, not just these, but > any new ones. > > But there must be some reason that xism are always shown in the > stringification, whether they are in effect or not in effect. But I > can't think what it might be. It would have been simpler for the > original design to only output them in the stringification when > different from the default. So there must be a reason why the plus or > minus of them is always output. Does that reason apply to these new > modifiers? The reason is so that interpolation under different flags works properly. Currently, if I have my $rx = qr/f./s; is stringifies to (?s-xim:f.), which means that when I interpolate it into a pattern with different flags "AFx" =~ /a$rx/i; the /i is 'cancelled' for the duration of the interpolation (and /s activated). If it were changed to stringify to (?s:f.) only, the match above would change from failing to passing. So yes, this applies to your new modifiers as well. Every stringified qr// should include a Cx flag of some kind. The only sane alternative would be to break compat once, now, by changing the stringification to something like (?~s:f.), using a new pattern which guarantees to set all non-specified flags to the default for the duration of the group rather than leaving them as they were outside. This would allow adding more flags in the future without breaking compat more than is strictly necessary. BenThread Previous | Thread Next