develooper Front page | perl.perl5.porters | Postings from August 2010

Re: RFC: New regex modifier flags; also the whimsical nature of backward compatibility; new 'r' flag has issues

Thread Previous | Thread Next
From:
Ævar Arnfjörð Bjarmason
Date:
August 6, 2010 17:28
Subject:
Re: RFC: New regex modifier flags; also the whimsical nature of backward compatibility; new 'r' flag has issues
Message ID:
AANLkTi=wwr1ZzBWS9C7kH7n0u+Nsw5ir1uCbvbfO24Eo@mail.gmail.com
On Fri, Aug 6, 2010 at 22:45, Jan Dubois <jand@activestate.com> wrote:
> On Fri, 06 Aug 2010, David Golden wrote:
>>
>> So that's my proposal:
>>
>> * use "U", "L", and either "d" (for "dual"/"dumb") or "t" (for
>> "text"/"traditional")
>> * throw a syntax error if more than one of these appears in the list
>> of modifiers
>> * leave the run-on deprecation as is and make run-ons a syntax error
>> in 5.16 to eliminate any future conflict issue
>>
>> That's simple and fixes the problem now without messing with features,
>> making assumptions about parsing ambiguous situations or introducing
>> wacky dual-letter regex modifiers.
>>
>> All those in favor?
>
> +1
>
> We could even make /u and /l aliases for /U and /L in 5.16 to return
> to all lowercase modifiers if we really wanted to (e.g. for aesthetic
> reasons).  But that doesn't have to be decided for quite a while...

+0.5

I must say I don't like the tradeoff of making users pound their shift
keys in perpetuity to produce /UL instead of /ul to maintain backwards
compatibility with an unlikely-to-occur bit of syntax.

Has anyone done tests to find out if cases like C</foo/lt "bar">
actually occur in the wild (e.g. on CPAN). Or is this just a runaway
backwards compat hypothetical?

But a single key, upper case or not, is less complex than the
previously discussed two-key combo.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About