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