demerphq wrote: > On 4 August 2010 15:38, karl williamson <public@khwilliamson.com> wrote: >> Aristotle Pagaltzis wrote: >>> * Ben Morrow <ben@morrow.me.uk> [2010-08-01 22:35]: >>>> My alternative suggestion was to introduce a new grouping >>>> construct, which I tentatively called (?~sixm:) (I don't much >>>> like that, but there aren't many alternatives at this point), >>>> which *does* do what you expect; and use that for >>>> stringification instead. That way we change the stringification >>>> once, now, and then never again. >>> I’m unsure about how good an idea that is. >>> >>> Presumably the defaults can change in a future version of Perl, >>> in which case a stringified pattern that uses this syntax will >>> mean different things on different Perl versions. In some cases >>> this will even magically do what you want, but it could equally >>> be a pitfall. >> FWIW, I have given this some thought, and came to the conclusion that Perl >> is almost certainly never going to change the defaults, because of the >> backward compatibility issues. > > Except that its been discussed many times that being able to specify > the default flags in a lexically scoped manner would be a useful > feature. So while it might be true that /perl/ will not change the > default flags, it is quite conceivable that perl will provide the user > a way to do so. Certainly, but it's not relevant here, as this construct would not be affected by those. (I now think a period is better than an underscore, so will use that in the examples.) (?.:foo) would mean this cluster does not inherit the surrounding flags, but uses the /perl/ default ones. (.x:foo) means this cluster does not inherit the surrounding flags, but uses the /perl/ default ones, but also the x modifier is selected, whether or not it is a /perl/ default. Whatever the user has chosen to be the default, it will be shown in the stringification iff it differs from the /perl/ default.Thread Previous | Thread Next