Front page | perl.perl5.porters |
Postings from February 2012
On Mon, Jan 30, 2012 at 11:20:10AM +0100, Abigail wrote:
> On Mon, Jan 30, 2012 at 07:51:41AM +0100, Steffen Mueller wrote:
> > On 01/30/2012 03:21 AM, David Golden wrote:
> >> Jesse's vision included the notion that changes should happen
> >> lexically under in a declared version block, whenever possible. So in
> >> this case, perhaps the deprecation warning should only occur under
> >> "use v5.16"? Frankly, I think the lexical version declarations are
> >> going to be horribly confusing and I question whether that's the right
> >> path forward or whether a simpler policy change would be more
> >> user-friendly.
> >
> > It seems to me like deprecation warnings should be lexical in a "use
> > 5.future" enabled block IF the deprecated feature is only removed in
> > "explicit 5.future enabled" code and continues to be supported
> > indefinitely in older versions (whether explicit or implicit).
> > Otherwise, we may as well remove the deprecated feature (after
> > deprecation) entirely as barely anybody can tolerate deprecation
> > warnings.
>
>
> Right. But if it's going to be removed only with some feature enabled,
> a new meaning will also only occur with said feature enabled.
>
> Which means that if a subroutine is documented as "takes a pattern as
> first argument", I would not be able to pass it '\w{foo}', as its meaning
> will be different depending on whether the sub uses the pattern with
> said feature enabled or without.
>
> Which seems like a bad idea to me.
That's a good point which I'd not thought of. Because patterns weren't
first-class (and sort of still aren't quite), it's normal to pass them as
strings. Whilst we could annotate regular expression *objects* with
metadata about the lexical context of their compilation, we can't with
strings.
Which makes it "really hard" to sanely try to support more than one
variation of regular expression syntax in the same interpreter.
Nicholas Clark
Thread Previous
|
Thread Next