Front page | perl.perl5.porters |
Postings from May 2010
On 18 May 2010 20:29, Jesse Vincent <jesse@fsck.com> wrote: > On Tue, May 18, 2010 at 06:20:15PM +0000, ?var Arnfj?r? Bjarmason wrote: >> On Tue, May 18, 2010 at 17:52, karl williamson <public@khwilliamson.com> wrote: >> > I asked Yves privately about this, and he wonders if it is worth trying to >> > not break constructs like '/foo/lt +2' >> >> I don't think it's worth it. We should just pick the modifier letters >> that make sense and not bend over backwards to be backwards compatible >> with a *very* small amount of code out there. > > I'd rather we design a solution that doesn't break backward > compatibility, no matter how much code we _think_ it might break. If > that turns out to be completely untenable, then we can talk about how we > hurt our users. I have to say that while I tend to agree with you in general on this one I think the boat already sailed. For instance, what characters can follow an s/// expression and a m// expression vary. So, on one hand we have stuff like: m/..../ge +1 which is a syntax error, but m/..../le +1 is a valid expression, yet s/...//ge +1 is interpreted as (s/...//ge) (+1). Given how muddy the waters already are IMO this type of breakage is only of interest to golfers. And is likely to involve only a mere handful of scripts who probably aren't going to upgrade anyway. Anyone sane puts a space after a regex and its modifiers anyway IMO. Anyway, if we really are going to care about this now I really think we aught to introduce deprecation warning when a character is encountered immediately following a regex pattern (of any sort) that is not a legal modifier so that we dont have to worry about it ever again. And I will note that the introduction of /p was achieved without anyone reporting any problems like this. Cheers, yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next