Eric Brine wrote: > On Fri, Aug 6, 2010 at 7:36 AM, karl williamson <public@khwilliamson.com > <mailto:public@khwilliamson.com>> wrote: > > I did an analysis of this, and it turns out that the only ambiguous > case is 's/foo/bar/le'. > > > $ perl -c -e'/foo/le 1' > -e syntax OK This is not ambiguous. It has to mean what it currently does because 'e' is not valid except in a substitute. > > $ perl -c -e'/foo/lt 1' > -e syntax OK > This is not ambiguous, because the l and t would not be valid together as regex modifiers. It has to mean what it currently does. > $ perl -c -e's/foo/bar/le 1' > -e syntax OK This is the one that is ambiguous. It would be resolved to mean what it currently does, with a deprecation warning. It currently has such a warning, but that could be customized in this single case to mention the other possible meaning. > > $ perl -c -e's/foo/bar/lt 1' > -e syntax OK This is not ambiguous because the l and t would not be valid together as regex modifiers. It has to mean what it currently does. > > That's 4 for "/l" alone, not counting the various permutations of > modifiers that you could place before the "l". So in reality it still is just one. > > On Fri, Aug 6, 2010 at 7:36 AM, karl williamson <public@khwilliamson.com > <mailto:public@khwilliamson.com>> wrote: > > Why can't we just say in the pods and warning message that '/le' > must be written as '/el' in 5.14? > > > Because it doesn't help. > > $ perl -c -e's/foo/bar/ele 1' > -e syntax OK > I misspoke. The ambiguity is for any combination in a substitute ending in 'le'. But I don't think that's materially different from what I said. So my view is that written properly, it does help.Thread Previous | Thread Next